PDA

View Full Version : Ut Video Codec Suite - a new lossless video codec for Windows!


Pages : [1] 2 3

tobinaka
20th December 2008, 11:29
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
20th December 2008, 15:19
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
20th December 2008, 16:46
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
20th December 2008, 21:54
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
21st December 2008, 00:25
Interesting ;) Please ask him if he'll compile a x64 version (if he can get hold of a 64bit proc tho ;))

video_magic
21st December 2008, 03:33
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
21st December 2008, 03:49
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
21st December 2008, 03:52
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
21st December 2008, 04:08
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
21st December 2008, 05:25
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
21st December 2008, 16:37
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
21st December 2008, 19:40
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
21st December 2008, 20:09
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
21st December 2008, 21:00
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
21st December 2008, 21:10
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
22nd December 2008, 01:08
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
22nd December 2008, 02:39
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
22nd December 2008, 03:12
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
22nd December 2008, 03:42
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
22nd December 2008, 07:45
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
22nd December 2008, 12:21
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
22nd December 2008, 12:31
[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
22nd December 2008, 13:25
I installed 'Microsoft Visual C++ 2008 Redistributable Package (x86)' and it still doesn't install.

tobinaka
22nd December 2008, 13:28
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
22nd December 2008, 13:31
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
22nd December 2008, 14:58
I've solved the problem by reinstalling the .net frameworks. I'll post comments on HD 720p and 1080p performance at RGB.

tobinaka
22nd December 2008, 15:40
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
22nd December 2008, 16:46
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
22nd December 2008, 17:57
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
22nd December 2008, 18:09
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
22nd December 2008, 20:03
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
22nd December 2008, 20:15
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
23rd December 2008, 15:31
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
31st December 2008, 03:05
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
31st December 2008, 15:54
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
31st December 2008, 16:35
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
31st December 2008, 17:02
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
4th January 2009, 13:35
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
4th January 2009, 14:17
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
5th January 2009, 06:36
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
5th January 2009, 16:07
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
6th January 2009, 15:06
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
8th January 2009, 17:48
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
9th January 2009, 03:05
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
11th February 2009, 08:55
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
11th February 2009, 09:24
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
11th February 2009, 09:27
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
12th February 2009, 01:53
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
12th February 2009, 02:00
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
12th February 2009, 15:23
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.

easy2Bcheesy
13th February 2009, 14:38
Hi, please let me know when my suggestion is included!

easy2Bcheesy
13th February 2009, 14:38
Hi, please let me know when my suggestion is included!

vsv
14th March 2009, 13:35
Ask same as easy2Bcheesy ;)

easy2Bcheesy
22nd March 2009, 17:42
Any news on when UT Codec will be updated with the fix I suggested? It seems a very easy thing to do!

What new plans are there for improving the codec? Can compression ratios improve, even if you need more CPU power? I love it and use it for realtime HD capture virtually every day.

johnsonlam
24th March 2009, 06:51
Any news on when UT Codec will be updated with the fix I suggested? It seems a very easy thing to do!

What new plans are there for improving the codec? Can compression ratios improve, even if you need more CPU power? I love it and use it for realtime HD capture virtually every day.

I surfed to author's site (Japanese), seems he's doing the codec among his large hobby list, so don't expect him to update often.

And I've use it instead of HuffYUV, it's very stable and not much room to improve, of course you can suggest your good idea through "tobinaka" san.

easy2Bcheesy
24th March 2009, 11:35
To be fair, the author himself says that he wants to match Lagarith compression. As I said, I love UT Codec and use it every day, but its compression limit appears to be similar to Huffyuv with adaptive frames (some way off Lagarith) and having to reset the codec's compression scheme every time I switch programs is a bit of a pain that's easily fixed.

easy2Bcheesy
22nd April 2009, 19:15
Another bug I have found is that sometimes the amount of threads being used is set to 105 (!). It seems to happen if I use UT in After Effects, then go back to capturing using it in VirtualDub.

Chikuzen
8th July 2009, 15:49
version 5.2.3 available.

Bug fixes * common: rarely outputs broken frame when encoding.

tobinaka
9th July 2009, 12:02
I'm sorry I haven't written in so long. I had a trouble with my graphic board etc. It's been a long time since I visited the forum last.

As Chikuzen said above, Ut Video Codec Suite version 5.2.3 is available now.
readme (English) (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.2.3-readme.en.html)
installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.2.3.msi)
source (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.2.3-src.zip)

easy2Bcheesy, I'm afraid that the author may not be up for your suggestion now. He has never said so, but I'm sorry I can't help saying so, though I think it well-worth considering. Please wait with patience. It's opensourced, then it could be faster to fix it up by yourselves on the forum.

By the way, though it's not the main topic here, AMV2 and 3 were also updated. And another new lossless video codec "ZeroCodec" was just released yesterday, but I've not tested it yet. While it's important to note ZeroCodec's author says it's still full of bugs, a famous news site in Japan picked it up and it's drawed attentions.

-AMV Video Codec (Shareware)
http://amamaman.hp.infoseek.co.jp/

-ZeroCodec v1.0.0 (Freeware not opensouced - ATTENTION! all in Japanese)
http://xrowcc.blog.shinobi.jp/Entry/386/

easy2Bcheesy
12th July 2009, 10:05
Zerocodec doesn't seem to work on my Vista x64. It just won't install.

I'm really disappointed that the codec settings for UT aren't being stored properly. It's the only annoying thing about what is otherwise a great codec. It is an obvious problem and if I could fix it myself, I would...

I do find that AMV has far lower CPU utilisation though and the file sizes are much smaller in most cases, but it loses its efficiency when you set every frame to be a key frame, which I need for my purposes.

Leeloo Minaï
14th July 2009, 21:09
Zerocodec seems to have 2 problems :
- inf install file is missing some registry params to get a proper install (at least on XP 32bits)
- once inf file correctly configured, i tried to install the codec but it is not detected (i tried with VirtualDub)

Chikuzen
8th August 2009, 16:01
Current version is 5.3.1
ReadMe (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.3.1-readme.en.html)
Installser (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.3.1.msi)
Source (http://umezawa.dyndns.info/archive/utvideo/utvideo-5.3.1-src.zip)

Version 5.3.1
Bug fixes
ULY0: fixed frame dividing method.

Version 5.3.0
New features
ULY0: Add support for YUY2 input when encoding.(but low speed)
ULY0: Add support for YUY2 output when decoding. (but low speed)

tobinaka
30th August 2009, 14:07
Ut Video Codec Suite ver 6.0.0 has been just released today.

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

For all formats: Added the particular process for the interlaced images.

Support for interlacing concretely represents that:

-In intra-frame prediction, to be adapted to interlaced images, it compares with the pixels two lines above. But, it's only on the case of "predict median". With "predict left", it doesn't "compare with upper pixels", then there is no difference between treating it as interlaced and treating it as progressive.

-In ULY0 with RGB and YUV422 inputs/outputs, it coverts into YUV420 with a suitable conversion equation for interlaced images. As a result, in ULY0 you must do accurate setting about whether the image is interlaced or not. Otherwise, the image would be encoded with strange chroma informations.
On the other hand, in the cases of ULRG, ULRA and ULY2, there is no difference between treating it as interlaced and treating it as progressive, except for the compression efficiency. But it should be good to set properly whether the image is interlaced or not.

GoldDragon
4th September 2009, 02:55
I just recently ran across this thread and the ut codec. When I attempted to install 6.0.0 I encountered the "installer was interrupted before..." error every time. I tried reinstalling the vc runtimes and the .net framework--still got the error. I pulled the utvideo.dll out of the .msi file and tried registering it manually, but that also failed. After this I downloaded version 5.3.1 and it installed perfectly on the first try. I did a quick capture test in virtualdub and confirmed that the codec works. When I tried to install 6.0.0 on top of 5.3.1, though, I was greeted with the same error and the installation failed.

Since 5.3.1 installed correctly it seems my machine has all the required dependencies, unless something changed for 6.0.0. Could I be missing a supporting file? Could there be an issue with the installer?

Thanks!

Midzuki
4th September 2009, 03:41
I just recently ran across this thread and the ut codec. When I attempted to install 6.0.0 I encountered the "installer was interrupted before..." error every time.

...

After this I downloaded version 5.3.1 and it installed perfectly on the first try. I did a quick capture test in virtualdub and confirmed that the codec works. When I tried to install 6.0.0 on top of 5.3.1, though, I was greeted with the same error and the installation failed.

Since 5.3.1 installed correctly it seems my machine has all the required dependencies, unless something changed for 6.0.0. Could I be missing a supporting file? Could there be an issue with the installer?

Well, at least you did manage to install an older version. On this computer, I can't install neither version 6, nor 5.3. :( I think the author of the codec should give a try to the goode and olde «.INF file method». :devil:

tobinaka
4th September 2009, 13:45
I just recently ran across this thread and the ut codec. When I attempted to install 6.0.0 I encountered the "installer was interrupted before..." error every time. I tried reinstalling the vc runtimes and the .net framework--still got the error. I pulled the utvideo.dll out of the .msi file and tried registering it manually, but that also failed. After this I downloaded version 5.3.1 and it installed perfectly on the first try. I did a quick capture test in virtualdub and confirmed that the codec works. When I tried to install 6.0.0 on top of 5.3.1, though, I was greeted with the same error and the installation failed.

Since 5.3.1 installed correctly it seems my machine has all the required dependencies, unless something changed for 6.0.0. Could I be missing a supporting file? Could there be an issue with the installer?

Thanks!

Well, at least you did manage to install an older version. On this computer, I can't install neither version 6, nor 5.3. :( I think the author of the codec should give a try to the goode and olde «.INF file method». :devil:

Thank for your reports. The same error was commented on the author's blog by another one. Certainly, 6.0.0 would have something wrong with its installer. Until it gets fixed, try 5.3.1 which I've successed installing. If you failed with 5.3.1, try to uninstall the codec (by "Add or Remove Programs" in "Control Panel.")

About 5.3.1, see the post by Chikuzen above.
http://forum.doom9.org/showpost.php?p=1312610&postcount=62

Leeloo Minaï
5th September 2009, 22:26
For those who have problems with MSI installer, here is a zipped INF installer for revision 5.3.1 (http://www.megaupload.com/?d=WVJKJC8I)
Of course, i maintained license and readme texts from the author in the archive.

I also tried with revision 6.0.0, but without luck...

GoldDragon
5th September 2009, 22:30
For those who have problems with MSI installer, here is a zipped INF installer for revision 5.3.1 (http://www.megaupload.com/?d=WVJKJC8I)
Of course, i maintained license and readme texts from the author in the archive.

I also tried with revision 6.0.0, but without luck...

Thanks for that. Since I wasn't able to install the codec manually I'm wondering if there could be something wrong with the .dll itself.

Looking forward to a new release...

tobinaka
7th September 2009, 15:23
Ut Video Codec Suite ver 6.0.2 . I tried to install it and successed.

-Change dynamic link into static link.
The author said this updating may resolve some of the errors on its install.
But he don't have the enviroment that can recreate the errors reported. If you can't install nor use this updated version, please report here.

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

He didn't like static link very much because of its filesize, but this time he compared the filesize between dynamic link and static link actually and came to think it not bad. He will release the newer version in static link for the future.

GoldDragon
7th September 2009, 16:44
Excellent. I can confirm that v6.0.2 installs and works perfectly.

124k isn't bad for the filesize. I've seen MUCH larger .dlls elsewhere (looking @ you, Adobe).

:thanks:

Midzuki
7th September 2009, 22:40
For those who have problems with MSI installer, here is a zipped INF installer for revision 5.3.1 (http://www.megaupload.com/?d=WVJKJC8I)
Of course, i maintained license and readme texts from the author in the archive.

:goodpost: :goodpost: and :thanks: :thanks: :thanks:

Leeloo Minaï
8th September 2009, 13:15
INF installer for revision 6.0.2 (http://www.megaupload.com/?d=6COBN0VD) :)

tobinaka
20th September 2009, 01:11
Ut Video Codec Suite ver 6.0.2 . I installed it successfully.

-common: Add option to set frame divide count to # of logical processors.

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

creamyhorror
21st September 2009, 14:14
Thank you for the regular updates, tobinaka. And much thanks to Takeshi for his hard work in providing this wonderful codec to everyone :thanks:

JoeH
1st October 2009, 18:41
Just wanted to thank everyone involved with this. I was using Lagarith to edit HD videos, but have now switched to UT.

I did a pretty extensive study of speed and video quality with Lagarith, Huffyuv, and UT, and while UT-RGB and Lagarith-RGB provide 100% identical output quality (confirmed with the MSU video quality measurement tool), the UT-RGB codec encodes to x264 at over twice the speed of the Lagarith codec on a Core i7 overclocked to 3.6GHz. I am getting 1080p encoding at well faster than realtime using this codec, something totally unthinkable with Lagarith or Huffyuv, with no quality hit. Thanks!!!
:thanks:

Chikuzen
22nd October 2009, 15:40
ver7.0.0

readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.0-readme.en.html)/installer(x86) (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.0-x86.msi)(x64) (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.0-x64.msi)/source (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.0-src.zip)

New features:
 Add x64 version. Both x64 version DLL and x86 version DLL are included in x64 version installer.
Others:
 DLL is now installed under System32/SysWOW64 directory instead of Program Files directory.

Boolsheet
22nd October 2009, 18:45
A 64 bit version, exactly what I needed! And it works perfectly.

:thanks:

Midzuki
30th October 2009, 23:39
INF installer for version 7.0.0 (x86):

http://forum.videohelp.com/images/guides/p2019210/utvideo-v_7.0.0-.zip

Leeloo Minaï
1st November 2009, 20:29
Midzuki : you missed to remove the version number of the dll name in the section :
[SourceDisksFiles]
utvideo.inf=1
utvideo602.dll=1

Midzuki
1st November 2009, 22:49
Midzuki : you missed to remove the version number of the dll name in the section :
[SourceDisksFiles]
utvideo.inf=1
utvideo602.dll=1

Thanks for the warning. :o
I will fix it A.S.A.P.

———

EDIT: fixed!

JeffBDVS
4th November 2009, 00:45
FYI, the x64 installer did not properly install the 32-bit version on Vista 64 (it didn't show up in 32-bit VirtualDub or GSpot). I had to run the x86 installer to get the 32-bit version.

-Jeff

Chikuzen
4th November 2009, 11:01
@JeffBDVS
According to umezawa's blog (http://umezawa.dyndns.info/wordpress/?p=1334),he is testing the improvement version to deal with that case now.

JeffBDVS
4th November 2009, 13:46
Thanks for the updated info, Chikuzen. :)

-Jeff

JeffBDVS
4th November 2009, 14:07
Bug report: UT crashes VirtualDub when MT AviSynth is used with HD video.

Steps to reproduce:

Export an HD 1080p30 or 720p60 UT file from your favorite editing program.
Create a simple MT AviSynth script. I used SetMTMode(2), AviSource("myUTfileHD.avi"), FlipHorizontal
Load the .avs script file into VirtualDub and set Compression to UT (any colorspace). Save as AVI from VirtualDub.


Result: VirtualDub crashes in the utvideo.dll module. About half the time you also get the attached error dialog from VirtualDub.

Workaround: Disable MT mode. Expect a 50% to 60% speed reduction in export from VirtualDub.

System:
Win Vista 64 SP2
Dual Quad-core Xeons
16 GB RAM
Nvidia GTX280
VirtualDub 32-bit
Both 32-bit and 64-bit versions of UT installed. The bug occurs even if the 32-bit version is the only one installed.

Notes:
- SetMTMode(3) and SetMTMode(4) also cause the crash.
- SD footage works in all cases with no crash.
- GreyScale(), known to be threadsafe with MT, also causes the crash with HD footage.

Chikuzen
4th November 2009, 16:12
@JeffBDVS
New version (7.0.1) seems to have been released a minute ago.
I recommend you to uninstall the existing one, and trying again with the upgrade product.
In my environment, it was not reproduced.

My system:
Windows7ultimate(x64)
Core2Quad Q9450
8GB RAM
RADEON HD3850
VirtualDub 1.9.7(x86)
AviSynth 2.5.8MT(SEt build)

SetMTMode(2,0)
AviSource("1280x720x60p_ULY0_10000frames.avi")
FlipHorizontal().FlipVertical()

Chikuzen
4th November 2009, 16:13
Version 7.0.1

readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-readme.en.html)/installer(x86) (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-x86.msi)(x64) (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-x64.msi)/source (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-src.zip)

Bug fixes:
 x64 version installer does not register DLLs properly on some OS environment.
Others:
 Shorten display names of codecs.

JeffBDVS
4th November 2009, 19:23
Thanks. I'll give it a try and post back.

-Jeff

JeffBDVS
4th November 2009, 22:54
Well, using the script that Chikuzen gave me, and my own script as posted above, I was able to successfully export from VirtualDub about 33% of the time with the latest UT version. Some more notes:


If I tried to configure the codec in VirtualDub's Compression dialog, then VirtualDub would always crash on export. If I accepted the default values, then I got the 33% success rate.
All external filters that I've tried that work flawlessly with the Lagarith codec and MT AviSynth will crash VirtualDub 100% of the time when exporting with the UT codec and MT AviSynth.


-Jeff

JeffBDVS
9th November 2009, 01:44
I think I should clarify: the crashes in VirtualDub result from *decoding* UT using MT AviSynth. Using Input video that is not compressed with UT and MT AviSynth, and then *exporting* to UT works perfectly 100% of the time (so far).

Things go pear-shaped in VirtualDub when the Input video has been compressed with UT and MT AviSynth is used.

Hope this helps,
-Jeff

JeffBDVS
10th November 2009, 01:37
Bug report version 7.01:
ULRA (RGB + Alpha) appears in the compressor lists for Adobe Premiere, Adobe After Effects and VirtualDub. It does *not* appear in the compressor list for Camtasia 6 or Daz Carrara 7. ULRG, ULY0 and ULY2 appear in all apps. It's only ULRA that's missing in some programs.

-Jeff

tobinaka
10th November 2009, 12:44
Oops, while I was concentrating on other issues, so many reports have been posted here. Thank you all! I'm now translating them in a hurry and must tell the developer ASAP.

Chikuzen
10th November 2009, 20:33
@Jeff
There are some uncertain points in your bug report.

1:Which is the version of your AviSynth?
 There are seven kinds of version of AviSynthMT that I know.
 (2.5.7 tsp's original, 2.5.7 mod by seraphy, 2.5.8 mod by seraphy, 2.5.8 mod by Jeremy Duncan, 2.5.8 mod by SEt, 2.6.0 pre-alpha by Willbert and 2.6.0 alpha by SEt)

2:Which codec of UtVideo are you using?
 UtVideo is 'Codec suite' that is not one codec but four codecs together in one.

3:What is the concrete value that you set to Ut when VirtualDub Crashes?

Bug report version 7.01:
ULRA (RGB + Alpha) appears in the compressor lists for Adobe Premiere, Adobe After Effects and VirtualDub. It does *not* appear in the compressor list for Camtasia 6 or Daz Carrara 7. ULRG, ULY0 and ULY2 appear in all apps. It's only ULRA that's missing in some programs.
Perhaps, it is not a bug.
ULRA is a codec for NLE/conposite Applications that uses RGBA.
ULRA doesn't accept the input other than RGBA. So,ULRA will not appear to the dialog without the function that an application pass the codec the stream with RGBA.
BTW,when compressing one video with ULRA in VirtualDub, are you adjusting output format of ColorDepth to 32bit RGB? If it doesn't do so,VirtualDub will be generated an error.
Because default Color Depth format in output of VirtualDub is RGB24.

JeffBDVS
10th November 2009, 21:18
1. tsp's original. I'm open to trying a different version if you (or anyone) thinks it'll be more stable or perform better.

2. I tried ULRG, ULY0 and ULY2.

3. I tried many variations. If I limited UT to one processor, then it worked. If I allowed 2 - 8 processors, it crashed. I tried both Predict Median and Predict Left. I used progressive video and interlaced video, and I checked Assume Interlaced Video when it was appropriate.

ULRA doesn't accept the input other than RGBA. So,ULRA will not appear to the dialog without the function that an application pass the codec the stream with RGBA.
Maybe you're right. The applications I mentioned will output RGB32 if the output codec supports it, but I'm not sure they pass RGB32 to the codec.

Thanks,
-Jeff

Chikuzen
12th November 2009, 08:11
@jeff

I transrate the content written in umezawa 's Blog (http://umezawa.dyndns.info/wordpress/?p=1356#more-1356) freely.
Wednesday, November 11, 2009
I tested on the following conditions for the confirmation of the problem.

Core 2 Quad Q6600 @3.00GHz
RAM 8GB
RADEON HD4350
Windows XP x86
AviSynth MT 0.7 http://www.avisynth.org/tsp/MT_07.zip
VirtualDub 1.9.7 x86
Ut Video Codec Suite 7.0.1 x86
#test script
SetMTMode(2,0)
AviSource("F:\cap20091103123626.avi") #ULY2,1280x720x60fps,8338frames
FlipHorizontal()

The crash never happened though I experimented many times.
:confused::confused::confused::confused::confused:

JeffBDVS
12th November 2009, 15:02
Good! Now we're getting somewhere! :) I, too, can encode the 720p60 stuff with 7.01. I couldn't with 7.00.

Does he have any 1080i or 1080p clips to test with? I'm currently getting VirtualDub to lock up after about 75-150 frames are processed using 1080i60 or 1080p30 with 7.01.

Thank you again for all your help with this. UT seems to be a terrific codec.

-Jeff

JoeH
23rd November 2009, 17:58
I love this codec! But now I moved to Windows 7 64bit, and for as often as I reinstall it (including the new 7.02 version) I can't get it to appear in either VirtualDubMod, VirtualDub 32 bit or VirtualDub 64 bit as a codec option! I used it without any problems on my Vista 32 bit, where it would appear immediately after install.

Should I try manually registering? I am logged on as admin, UAC is totally turned off, etc.
--------------------------------------------------
OK. I tried to register it manually, and I get the following error, with a command prompt opened as Administrator, and running from the SYSWOW64 directory:
"The module utvideo.dll was loaded but the entrey point DLLRegisterServer was not found. Make sure that utvideo.dll is a valid DLL or OCX file and then try again."

I do have a bunch of other codecs which properly installed, and in general my computer is working perfectly, so is something about the utvideo.dll 64 bit version which is incompatible with Windows 7 64?

Chikuzen
24th November 2009, 19:00
Version 7.0.2

readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.2-readme.en.html)/installer(for x86 OS (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.2-x86.msi))(for x64 OS (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.2-x64.msi))/source (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.2-src.zip)

Chenges:
 x86 version installer is now unable to be installed to x64 Windows.
 Modified some text.

Chikuzen
24th November 2009, 19:31
@JoeH
Umezawa seemed to have become Windows7 64bit user three days ago.
Perhaps, he had to have tested in his own latest environment before releasing 7.0.2.
And, the 7.0.2 installer(x64) worked normally in my environment (http://forum.doom9.org/showpost.php?p=1340963&postcount=85).

Does Japanese version of Windows7 have something different from the other countries?

JoeH
25th November 2009, 15:25
I'm glad to know some have been able to get it to work. I will continue testing. I just tested v7.0.2 on a different Vista32 install, and it worked perfectly.

@Chikuzen, just to confirm, after installation does it appear in the "Compression" settings in VirtualDub as a codec you can convert to? In theory there should be no difference between the Japanese and English versions of Windows.

JoeH
25th November 2009, 16:20
I installed version 6.1.0 of UTVideo successfully in Windows 7 64-bit. Of course, it only appears in the 32 bit Virtual Dub.

I still have not been able to get Version 7.0.2 to appear in VirtualDub after install. I have tried repairing, and removing and reinstalling.

I tried installing Lagarith 64 bit as a test and it installed correctly and appears in both the 32bit and 64bit versions of VirtualDub.

Chikuzen
25th November 2009, 17:50
@Chikuzen, just to confirm, after installation does it appear in the "Compression" settings in VirtualDub as a codec you can convert to? In theory there should be no difference between the Japanese and English versions of Windows.
Yes. Look this (http://img260.imageshack.us/img260/6742/myenvironment.jpg).
Which version of 7.0.2 did you install? x64? x86?

JoeH
26th November 2009, 07:53
x64.

I tried the x86 version as well, but obviously it didn't work.

JeffBDVS
13th December 2009, 00:50
7.02 still crashes VirtualDub when 1080p30 footage is flipped horizontally using an .avs script and AviSynth MT (as before). I did not test with 1080i footage this time.

-Jeff

Alante
12th January 2010, 21:57
How is Ut Video Codec Suite 7.0.2 compared to MLC 0.7, cause I couldn't install it on Windows 7. Might be a workaround to make it work, but I wonder if it's worth it... I'm new to lossles codecs, so far MLC is the only one i tried (not famous as others, i know - but I heard to many bad things about the rest). Since is "lossles" I don't see any room for quality comparisons, so that leaves Encoding speed, compression and end results (as in "completed successfully").

JoeH
13th January 2010, 17:22
How is Ut Video Codec Suite 7.0.2 compared to MLC 0.7, cause I couldn't install it on Windows 7.

I can't get UT 7.02 to install on Windows 7 either, but version 6 works just fine. Hopefully the author will fix this (hint, hint).

I haven't tried MLC, but UT is much faster than either Lagarith or Huffyuv (about 2x as fast as either), at least on a Core i7. It is the best lossless codec I have tried.

Alante
13th January 2010, 22:55
[QUOTE=Alante;1363168]How is Ut Video Codec Suite 7.0.2 compared to MLC 0.7, cause I couldn't install it on Windows 7. /QUOTE]

I can't get UT 7.02 to install on Windows 7 either, but version 6 works just fine. Hopefully the author will fix this (hint, hint).

I haven't tried MLC, but UT is much faster than either Lagarith or Huffyuv (about 2x as fast as either), at least on a Core i7. It is the best lossless codec I have tried.

Thanx, they I'll try to make it work and yeh, hope the author helps with a fix. ;)

Chikuzen
22nd January 2010, 16:55
I translate and reprint the content from author's blog (http://umezawa.dyndns.info/wordpress/?p=1468).


January 22, 2010
I have heard the case of failing in the installation on windows7 several times before.
Houever, the cause doesn't turn out.
Then, I want to ask users for cooperation in the investigation.

Respondent to a survey:
User of windows vista/7

How to:
1: Uninstall UtVideo that has already installed (Please use the control panel).
2: Install ver.6.1.0
3: Use vcavail.exe and confirm whether UtVideo can used.
4: Do from 1 to 3 of ver.7.0.0 , ver.7.0.1 and ver.7.0.2 similarly.

Content that should be reported:
1: your windows version (vista or 7 , 32bit or 64bit)
2: Video codecs that installed beside UtVideo.
3: whether to complete the installation of UtVideo safely.
4: whether UtVideo can be used ( result using vcavail.exe ).

note:
・Please uninstall all UtVideo before the investigation.
・Please use vcavail.exe for the check on whether UtVideo can be used.
・The user of 32bit windows must install only Utvideo for 32bit.
・about ver.7.0.0 , ver.7.0.1 and 7.0.2 ,the user of 64bit windows must install only Utvideo for 64bit
・The user of 32bit windows must use only vcavail-x86.exe.
・The user of 64bit windows must use both vcavail-x86.exe and vcavail-x64.exe.

link:
vcavail.exe (http://umezawa.dyndns.info/archive/vcavail/vcavail-20100121.zip) (tool for investigation, the installation is unnecessary)
UtVideo ver.6.1.0 (http://umezawa.dyndns.info/archive/utvideo/utvideo-6.1.0.msi)
UtVideo ver.7.0.0 for 32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.0-x86.msi) / for 64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.0-x64.msi)
UtVideo ver.7.0.1 for 32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-x86.msi) / for 64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.1-x64.msi)
UtVideo ver.7.0.2 for 32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.2-x86.msi) / for 64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-7.0.2-x64.msi)

Thanks for your Cooperation.

Umezawa Takeshi

Chikuzen
22nd January 2010, 17:38
in my case

OS: Windows7 64bit (Ultimate)

Other codecs:
・microsoft video1(32bit and 64bit)
・intell IYUV codec R2.0 (32bit and 64bit)
・Cinepack radius 1.10.0.11 (32bit only)
・Helix I420 YUV codec (32bit only)
・Lagarith Loassless codec 1.3.20 (32bit and 64bit)
・AMV2 MT codec 2.20g (32bit only)
・AMV3 codec 3.00g (32bit only)
・xvid 1.2.2 by Alexin (32bit only)
・VP6 vfw codec (VP60,VP61,VP62) 6.4.2.0 (32bit only)
・Windows media video 9 VCM (32bit only)
・ffdshow video codec (ffdshow truouts r3207) (32bit and 64bit)

Results:
ver.6.1.0: installation was completed safety, and there is no problem in use.
ver.7.0.0: installation was completed safety, and there is no problem in use.
ver.7.0.1: installation was completed safety, and there is no problem in use.
ver.7.0.2: installation was completed safety, and there is no problem in use.

JoeH
23rd January 2010, 20:56
OS: Windows7 64bit (Enterprise)

Other codecs:
I have the KLite Codec Pack (Full version) installed
・microsoft video1
・intell IYUV codec
・Cinepack radius
・Helix I420 YUV
・Lagarith Lossless codec
・ffdshow video codec

Results:
ver.6.1.0: installation completed, and appears in 32-bit version of VCAVAIL, but not in 64 bit version.
ver.7.0.0: installation completed (tried both 64 bit and 32 bit versions). Does NOT appear in 64 bit or 32 bit version of VCAVAIL.
ver.7.0.1: installation completed (tried both 64 bit and 32 bit versions). Does NOT appear in 64 bit or 32 bit version of VCAVAIL.
ver.7.0.2: 32 bit version did not install. 64 bit version installs. Does NOT appear in 64 bit or 32bit versions of VCAVAIL.

Summary: Only ver. 6.1.0 works.

Chikuzen
24th February 2010, 19:00
Version 7.0.4

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

Others:
Changed the way to register codecs again.

Translation from author's blog
This change point is only a change of the installer.
If the codec is not registered to your system with this installer,please double-click utvideo-x86.reg (or utvideo-x64.reg).
reg file is in C:\Program Files\utvideo .
If you came to be able to register by this change, please report on the following matters.
・your OS version
・whether reg file was used or not

zcream
5th March 2010, 12:08
Hi UMEZAWA san!
In this thread,
http://forums.virtualdub.org/index.php?act=ST&f=6&t=16116&st=0

squid_80 compiled a version of Huffyuv that could accept the HDYC output from the Blackmagic Intensity capture card.
There was some problems, as
>>>
the BlackMagic codec uses Rec. 601 coefficients if the width is 720 or less, and Rec. 709 coefficients if it's greater than 720
>>

squid_80 responded
>>>
for SD resolutions the intensity only offers UYVY. For 1280x720 and 1920x1080 it only offers HDYC. You can request UYVY@HD using the set custom video format dialog and it will succeed, but still delivers HDYC (or occassionally a blue screen error, something about driver has locked pages IIRC).
>>

I do not have access to my PC at the moment, and I will try Ut with Blackmagic Intensity and Virtualdub for capture in a few days.

I was basically wondering if you have tried Ut codec with HDYC input and if it works fine that way..

Chikuzen
9th March 2010, 15:39
@zcream
I questioned Umezawa on what you said.
He said "I am a user of Intensity. Because I am interested about this matter, let's investigate"

zcream
9th March 2010, 16:48
For Intensity and virtualdub capture, another important issue is from here...
http://forums.virtualdub.org/index.php?act=ST&f=6&t=18348

described well here..

http://www.etfinder.net/capturepics/

It looks that either Virtualdub or Huffyuv (or both) mess up the HDYC colorspace conversions.
So UT Video may need to be checked with color bars from a camcorder to confirm that the color values are correct..

>>>
I'm beginning to suspect that the issue is aliasing between the HDYC and UYVY formats. The HDYC format is a similar format to UYVY, except that it uses the Rec. 709 (HD) color space instead of Rec. 601 (SD). It looks like you have a couple of programs/codecs involved that are attempting to handle HDYC by simply pretending that it is UYVY.
>>>

>>>
Okay, I discovered the solution: Enable the filter chain, leave "Skip 24-bit conversion" unchecked, and clear the filter list.
This provides Huffy with 24 bit RGB I guess.
>>>

JoeH
11th March 2010, 18:04
Version 7.0.4

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

Others:
Changed the way to register codecs again.

Translation from author's blog

Bad news - it still doesn't work for me. Even after running the registry file it does not appear. I reverted again to version 6.1, which works fine.

Here is the error I get if I try to manually register the DLL (using regsrv32). My user is an Administrator and UAC is off:

"The module utvideo.dll was loaded but the entry point DLLRegisterServer was not found. Make sure that utvideo.dll is a valid DLL or OCX file and then try again."

Leeloo Minaï
12th March 2010, 00:33
For all users who meet problems with the official MSI installer, i have created a little package for you including latest 7.0.4 codecs, a batch file, an inf script and all the other files from the author.

Open a command prompt (in admin mode for Vista/7 if UAC enabled) and run the batch script "install.bat" : il will copy codec files to the right directories and then call the inf script to write all the necessary registry entries, including uninstall entry in add/remove section of the control panel.

For 32-bits systems (9x / NT) : install only 32-bits version of the codec
For 64-bits users (XP / Vista / 7) : install both 32 and 64-bits versions of the codec

Here is the link : http://www.megaupload.com/?d=ADM7ECXB

Chikuzen
16th April 2010, 12:54
version 7.1.1

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

Register DLL file with full path name.
Fix significant performance decrease in Athlon/Phenom-series processors.

johnsonlam
16th April 2010, 15:28
version 7.1.1

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

Register DLL file with full path name.
Fix significant performance decrease in Athlon/Phenom-series processors.

Thanks Chikuzen

JoeH
25th April 2010, 14:38
version 7.1.1

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

Register DLL file with full path name.
Fix significant performance decrease in Athlon/Phenom-series processors.

Thanks for continuing to develop this. I still am unable to get any version after version 6.1 to register on a Windows 7-64 bit machine. I have tried all the different versions posted since then, including the special version which Leeloo Minaï
built. I am really sorry about this, especially as I would like to get some 64-bit version of UT Video to work. If there is anything I can do to help testing please let me know.

On Windows XP 32-bit it installs perfectly.

Leeloo Minaï
26th April 2010, 10:36
JoeH : what program do you use to encode and is this a 32 or 64-bit version ?

I will check again my script, i didn't try yet the last release of utvideo codec.

JoeH
27th April 2010, 07:05
I use VirtualDubMod, but also have VirtualDub (32-bit) and VirtualDub (64-bit) installed. If I can get UTVideo 64-bit version to register, I will use VirtualDub 64-bit.

From the error messages that Windows gives if I try to manually register the codec using regsvr, it seems to me that the problems is that Windows is not recognizing it as a valid DLL file. So, from the little I know anyway, I don't think the problem is the install procedure / batch procedure, etc., but is some change in the code or compilation that is making some Windows installations think the DLL file is invalid. Just a guess.

squid_80
27th April 2010, 11:15
VFW codecs aren't installed by registering them.

Midzuki
28th April 2010, 04:50
VCM and ACM codecs must be registered through regedit —

— either manually,
or by double-clicking a properly-written .reg file.
A .INF installer will register the file(s) and will copy it/them to the system directory.

JoeH
28th April 2010, 17:02
OK, thanks for clearing that up. So, it's not a regsvr incompatibility then anyway.

Boolsheet
28th April 2010, 17:35
Edit: The VCM interface was moved from utvideo.dll to utv_vcm.dll in 8.5.1 version and above.

Have you checked the registry if there are the strings vidc.ulrg, vidc.ulra, vidc.uly0 and vidc.uly2 with the value utvideo.dll in "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32"?
The 32-bit codecs on 64-bit Windows are in "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32", but you already said they're working.

http://img168.imageshack.us/img168/184/vidc.png

Check C:\Windows\SysWOW64 for the 32-bit utvideo.dll (126'976 bytes - MD5: CC280F83C3BEE5E122F2A3B69D224507)
and C:\Windows\System32 for the 64-bit utvideo.dll (133'632 bytes - MD5: 0FB9C204339909A6FFB2075E1B30E98F).
Sizes and hashes are for version 7.1.1.

That should be all you need to get it working.

JoeH
29th April 2010, 19:25
Thanks for the info. I checked, and all registry keys and files are exactly as you stated. However, the UTVideo codecs do not appear, neither in the 32 bit version or the 64 bit version.

When I said that the 32 bit version appeared, I was referring to when I install version 7.1.1 on a 32-bit operating system. On Windows 7-64 bit, I have never gotten any UTVideo to work after version 6.1.

Boolsheet
29th April 2010, 21:22
When I said that the 32 bit version appeared, I was referring to when I install version 7.1.1 on a 32-bit operating system. On Windows 7-64 bit, I have never gotten any UTVideo to work after version 6.1.
Ah ok, mixed something up there then.

Don't know how you could track the error down.
Does it show up if you simply overwrite the utvideo.dll with the 6.1 version? Extract the files from the installer with this:
msiexec /a c:\utvideo-7.1.1-x64.msi /qb TARGETDIR=c:\out

Try absolute paths in the registry to link the vidc.ul* to the dll, somewhere outside the system folders.
Or you could use Process Monitor (http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx) to check if VirtualDub even touches the dll.
To rule out your specific configuration of Windows 7 you'd have to reinstall Windows on a second hard disk and test again. Or in a Virtual Machine, that's easier.

I only have a 32-bit version of Windows 7 running in a VM, all I can say is "it works there". :/

JoeH
1st May 2010, 07:43
I fixed it! Thanks for your help, Boolsheet, I never would have figured it out otherwise.

All the registry talk gave me the idea of searching through the registry to see where else utvideo.dll appeared. There were some other registry keys that were messed up - I'm not yet sure if from previous installs or from an error in the current installer - that were preventing Windows 64-bit from finding the codecs.

Here are the changes I made to enable the 32 and 64 bit versions:

Fixing this key enabled UTVideo 32 bit:
HKEY_USERS\S-1-5-21-445962267-61098652-3305859534-1000\Software\Microsoft\Windows NT\CurrentVersion\Drivers32
(the keys in this registry were set to the old "program files" directories; once I updated them the 32 bit versions appeared).

This key enabled UTVideo 64 bit:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Installer\Userdata\S-1-5-18\Components\641C5E112721E173C1CAE65BB3935D9B
Key: BB418FCA7B304794A947F5C82578888A
(this key was set to "C?\Windows" (etc.) instead of to "C:\Windows" (etc.). Once I changed the ? to : it worked.

Now, one more comment - I have never touched the registry as regards UTVideo before, so these changes, or lack of changes, were almost certainly all done by UTVideo's different installers (I've installed and uninstalled just about every version). So, it might be worthwhile to update the installers to fix these bugs if they are still present, or to remove them if left over on some computer from previous installs.

If someone could make sure the developer of UTVideo knows about this, that would be great - I know some of you are in contact with him. Thanks!

JoeH
1st May 2010, 09:11
It just happens I had to install a Windows 7 - 64 bit Enterprise in English this morning. I installed the latest version of UTVideo 7.1.1 64-bit and both the 32 and 64 bit codecs showed up just fine. So, I image my problem was related to a previous version of UTVideo causing conflict.

Leeloo Minaï
1st May 2010, 15:44
Damn, i come too late with my latest INF script :devil:

Good news for you, you finally got to resolve your install problem !
Surprisingly, the registry key you mention does not appear anywhere with official installer or in my INF scripts... certainly an old entry from a 5.xx or 6.xx release.


I promised i will continue to update a far simpler INF installation script, here is the new one for release 7.11 :
http://www.megaupload.com/?d=L0F8JWW5

It is designed for NT systems only (32/64 bits), i didn't put Win9x support, i don't think it will suffer to anyone. :p

Chikuzen
1st July 2010, 01:34
version 8.0.0

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

New feature
 Add DMO codec.

others
 64bit-installer has been changed.
 It install only 64bit-codec now.

NOTE of 64bit Windows users
 Please uninstall old version first if you hope to update.

easy2Bcheesy
11th July 2010, 12:57
Very happy that the author is supporting UT as a DirectShow (or DMO as he calls it) codec!

Just one problem: the DirectShow components do not support the encoding options as a property page. It seems we can only change them via the VFW component. This is a bit of a pain.

Can encoder properties be added to 8.0.1? And please can encoder settings be retained in registry so we don't need to change them with every session?

Chikuzen
25th July 2010, 05:13
Just one problem: the DirectShow components do not support the encoding options as a property page. It seems we can only change them via the VFW component. This is a bit of a pain.


A new post was written in Umezawa's blog two days ago.
I think that it is answer to your question.
http://umezawa.dyndns.info/wordpress/?p=1860

Reasons for UtVideo8.0.0 to use not ISpecifyPropertyPage/IPropertyPage interface but IAMVfwCompressDialogs interface are...

1.It takes serious time to mount ISpecifyPropertyPage/IPropertyPage interface.
 I think that a great internal change is necessary because UtVideo is originally made as VCM codec.
2.It was considerably easy for me to mount IAMVfwCompressDialogs interface on UtVideo.
3.The DirectShow capture software that I am using now can use only the IAMVfwCompressDialogs interface.

I want to mount ISpecifyPropertyPage/IPropertyPage interface on UtVideo. However, I can't get a good design yet.

Zarxrax
26th July 2010, 02:24
The vfw codecs don't save the settings. Is it supposed to?
I have to change the compression mode every time I use it.
The fast mode seems barely any faster than the high compression mode, but you can save quite some filesize with the high compression mode. So I don't see much reason to default to the high speed mode.

Edit: oops, I guess that was just mentioned 2 posts above :p

JoeH
27th July 2010, 07:43
I personally much prefer the high speed mode, as I notice a healthy speed up (maybe 10-20% if I remember correctly) when encoding to X264 through Sony Vegas.

Zarxrax
27th July 2010, 16:06
I personally much prefer the high speed mode, as I notice a healthy speed up (maybe 10-20% if I remember correctly) when encoding to X264 through Sony Vegas.

Really? I saw much lower speed up, something around the order of 5 seconds per minute. I guess it varies depending on the cpu.

Chikuzen
24th August 2010, 00:39
version 8.1.0

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

New features
* Encoder is now able to save configuration globally by encoder itself.
* Encoder is now able to ignore setting of cofiguration from codec client (e.g. editing software).

NOTE:
If you want to use these new features, check the checkbox that exists in "Global Configuation (start menu -> UtVideo codec suit -> Global Configuation)" beforehand.
When both are checked, the behavior of codec becomes like huffyuv,etc.
The setting of Global Configuations is shared with 32bit and 64bit.

Zarxrax
24th August 2010, 16:53
Sweet! Awesome update!

Mr_Khyron
5th September 2010, 10:49
version 8.2.0

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

New features:
Performance Improvements
* common: Speed up decoding. 20-30% for x86, 20-40% for x64 (if Core 2).

:)

Chikuzen
5th September 2010, 14:51
@Mr_Khyron
Oh, you fast :eek:

However, you are not writing an important thing ;)
NOTE:
The size of the decode table has increased to about 12KB because of speed-up.
This will invite making to low speed oppositely in CPU whose size of L1-cache is smaller than that of 16KB(e.g. Northwood).

Midzuki
5th September 2010, 15:05
Performance Improvements
* common: Speed up decoding. 20-30% for x86, 20-40% for x64 (if Core 2).

:eek: :)

Many :thanks:

Chikuzen
2nd October 2010, 20:36
version 8.2.1

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

Others
* ULY2: For the safety, set 255 to the field that might be interpreted as alpha channel when decoding.
* ULY0: For the safety, set 255 to the field that might be interpreted as alpha channel when decoding.

patrick_
3rd October 2010, 18:46
First time I read about this codec. Seems really interesting, but the help says it only supports limited range YV12. Because avisynth outputs full-range, when using this codec for an intermediate file, quality will be lost :(

Anyways, I will be able to use it for Vegas temporal renders, because that's RGB. So thank a lot.

poisondeathray
3rd October 2010, 19:15
First time I read about this codec. Seems really interesting, but the help says it only supports limited range YV12. Because avisynth outputs full-range, when using this codec for an intermediate file, quality will be lost :(

Anyways, I will be able to use it for Vegas temporal renders, because that's RGB. So thank a lot.


I just tested it and YV12 [0-255] input = YV12 [0-255] output

Perhaps the documentation is old, or what it is saying is if you allow UT to do the RGB=>YV12 conversion (instead of doing it yourself e.g. through avisynth, the range is limited (ie. it uses Rec.601 matrix)

patrick_
6th October 2010, 14:40
Thanks a lot for verifying. I'm really glad it does keep the fullrange. Now it's a lot more usefull than I first thought!

Chikuzen
11th October 2010, 14:03
version 8.3.0

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

Performance Improvements
* ULY2: Speed up decoding on fast mode. About 12% if Core 2.
* ULY0: Speed up decoding on fast mode. About 5% if Core 2.

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

MatLz
11th October 2010, 15:35
Simply magic...

ARIGATÔ GOZAIMASU !!!

( :thanks: )

Mr_Khyron
18th October 2010, 07:47
version 8.4.0

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

Performance Improvements

* ULRG: Speed up decoding "Predict left" video to RGB24 and RGB32. 14% for x86, 6% for x64 (if Core 2).
* ULRA: Speed up decoding "Predict left" video to RGBA. 17% for x86, 6% for x64 (if Core 2).

johnsonlam
19th October 2010, 14:44
version 8.4.0
Performance Improvements

* ULRG: Speed up decoding "Predict left" video to RGB24 and RGB32. 14% for x86, 6% for x64 (if Core 2).
* ULRA: Speed up decoding "Predict left" video to RGBA. 17% for x86, 6% for x64 (if Core 2).

Terrific codec, thanks for the link!

Chikuzen
2nd November 2010, 20:36
version 8.5.0

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

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

_gl
2nd November 2010, 21:27
I just wanted to thank the author for these excellent codecs.

I've used HuffYuv and Lagarith quite a bit, and the decoding speed of UT is just amazing. Using WMPlayer, a 1080p/25fps video (using 'fast decode' encoding) uses about 18-20% of my 3.4Ghz Intel quad (Q6600), so easily real-time playback without any glitches.

Chikuzen
3rd November 2010, 00:21
@_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
3rd November 2010, 00:25
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
4th November 2010, 07:16
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
8th November 2010, 09:50
: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
14th November 2010, 01:18
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
14th November 2010, 09:08
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
7th December 2010, 13:52
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
13th December 2010, 09:18
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
28th January 2011, 08:53
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
28th January 2011, 18:14
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
15th February 2011, 01:57
@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
15th February 2011, 04:48
Also, any chance of ut video on Mac ? Maybe only a decoder to begin with ?

JeffBDVS
16th February 2011, 18:55
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
16th February 2011, 21:32
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
16th February 2011, 22:13
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
16th February 2011, 22:40
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
16th February 2011, 23:07
@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
16th February 2011, 23:39
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
17th February 2011, 01:55
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
17th February 2011, 18:17
@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
17th February 2011, 22:02
@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
17th February 2011, 22:11
codecs.com - codes descriptions on this site are way not accurate and misleading. Never heard of this site before.


Andrew

JeffBDVS
17th February 2011, 22:21
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
18th February 2011, 17:23
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
18th February 2011, 19:07
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
18th February 2011, 19:30
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
18th February 2011, 19:46
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
18th February 2011, 23:54
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
26th February 2011, 02:04
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
21st March 2011, 23:32
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
22nd March 2011, 14:48
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
26th March 2011, 06:29
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
2nd May 2011, 21:47
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
3rd May 2011, 15:29
version 9.0.0
New features
- Add DMO decoder.
Ehm, what exactly does it mean for Windows 7 users like me? :stupid:

Chikuzen
3rd May 2011, 17:42
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
4th May 2011, 06:57
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
4th May 2011, 08:47
@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
4th May 2011, 11:11
@kypec I could use DirectShowSource because I use MT Avisynth build, AVISource do not work properly.
yup.

kypec
4th May 2011, 14:27
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
4th May 2011, 17:52
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
5th May 2011, 06:44
@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
5th May 2011, 07:25
@Chikuzen
How I can known which splitter I am using during call DirectShowSource? I have installed ffdshow and matroska.

GraphEdit

yup
5th May 2011, 08:24
@Chikuzen
I see only AVI Splitter.
Changing to RGB work without problem, but I am need YUY2.
yup.

Chikuzen
5th May 2011, 10:26
@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
5th May 2011, 18:11
@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
6th May 2011, 05:10
@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
7th May 2011, 08:40
@Chikuzen
Under Win7 work all release 2.58 and 2.6 for Win XP need update DirectShowsource.dll 27.01.2010.
yup.

3ds
11th May 2011, 13:40
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
11th May 2011, 16:09
normal?

There is a possibility though it is a special case.

3ds
12th May 2011, 09:35
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

JoeH
13th May 2011, 08:36
Lagarith generally compresses a little more, but UT is much, much, much faster than Lagarith, both at encoding and especially at decoding.

Chikuzen
13th May 2011, 13:48
OK, than should Ut generally better compress than Lagarith?


No.
UT uses Huffman coding for entropy encoding algorithm similar huffyuv.
On the other hand, Lagarith uses RangeCoder.
RangeCoder does better (but slower) compression than Huffman.
(This is the same as the difference between zip and 7zip.)

Umezawa was talking that RangeCoder is scheduled to be introduced into UT on his blogpost before.
however, no one(included Umezawa) knows when it comes.

Stephen R. Savage
9th June 2011, 02:26
I'm having trouble using the latest version of UTVideo. I upgraded from v7.1 (first post of this thread) to v9.0 from the author's website. However, I can't find the new version listed in VirtualDub, nor can I successfully connect any pins to it in GraphStudio. I see that sometime in v8.x the VfW frontend was moved to a separate DLL, so perhaps that has something to do with this. Regardless, I have been forced to continue using the old v7.1 release. Any help on this issue would be appreciated.

Boolsheet
9th June 2011, 04:11
Yep, the vcm driver entry point moved from utvideo.dll to utv_vcm.dll with one of the updates.
You could search the registry if there's something still pointing to utvideo.dll. Here's where it is usually located:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32 (for 32-bit applications on win64)

I don't use the installer myself so I can't say if this is an error and the installer forgets to delete/change the old entries.

Mr_Khyron
28th June 2011, 21:31
version 9.0.1

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

Bug fixes:

- DMO decoder returns inconsistent formats when enumerates output formats.

Chikuzen
4th August 2011, 15:39
Version 9.0.3

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.3-readme.en.html) / installer (32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.3-x86.msi))(64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.3-x64.msi)) / source
(http://umezawa.dyndns.info/archive/utvideo/utvideo-9.0.3-src.zip)
Bug fixes
ULY2: DMO encoder does not accept the format that is suggested by itself when the input format is not RGB24/32.
ULY0: DMO encoder does not accept the format that is suggested by itself when the input format is not RGB24/32.

Others
DMO encoders and decoders now does not check some part of input/ouput formats.

smok3
9th August 2011, 10:12
q1: on 64bit win7 i would install 32 and 64 bit version to get in/out workflow between 32bit virtualdub/avisynth and 64bit premiere 5.5, or .... ?
q2: would there be a massive difference between 32bit version versus 64bit version with virtualdub 32/64?

patrick_
9th August 2011, 14:38
q1: yes

smok3
27th August 2011, 18:38
q3: is there a mac version?

mp3dom
4th September 2011, 13:10
Yep, the vcm driver entry point moved from utvideo.dll to utv_vcm.dll with one of the updates.
You could search the registry if there's something still pointing to utvideo.dll. Here's where it is usually located:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32 (for 32-bit applications on win64)


Version 8.5.0 is the latest that I am able to use. All other new versions simply doesn't appear in VDub (and After Effects, for example) as available codecs (for both x86 and x64). I've checked that path and it points to the exact dll (utv_vcm.dll). Also the dll is physically present. The decoder strangely works with WMP and GraphEdit. Any suggestion?

Midzuki
4th September 2011, 22:21
Version 8.5.0 is the latest that I am able to use. All other new versions simply doesn't appear in VDub (and After Effects, for example) as available codecs (for both x86 and x64). I've checked that path and it points to the exact dll (utv_vcm.dll). Also the dll is physically present. The decoder strangely works with WMP and GraphEdit.

Any suggestion?

Yes — unpack the .msi file with "Universal Extractor", copy the DLLs to an 8.3-named folder (e.g., "UTVID903"), rename 'utv_vcm.dll' to 'utvid903.dll', create the file "utvid903.INF" :devil:

; UT Video Codec Suite 9.0.3

[Version]
Signature="$CHICAGO$"
Class=Media

[DefaultInstall]
CopyFiles=utvideo.Files.Inf,utvideo.Files.Dll
AddReg=utvideo.AddReg
UpdateInis=utvideo.UpdateIni
MediaType=SOFTWARE

[DefaultUnInstall]
DelFiles=utvideo.Files.Inf,utvideo.Files.Dll,utvideo.Files.Pnf
DelReg=utvideo.AddReg
UpdateInis=utvideo.UpdateIni.Del

[SourceDisksNames]
1="UT Video Lossless Codec 9.0.3","",1

[SourceDisksFiles]
utvid903.inf=1
utvid903.dll=1
utvideo.dll=1

[DestinationDirs]
utvideo.Files.Inf=17 ; windows\inf
utvideo.Files.Dll=11 ; windows\system

[utvideo.Files.Inf]
utvid903.inf

[utvideo.Files.Dll]
utvid903.dll
utvideo.dll

[utvideo.Files.Pnf]
utvid903.pnf

[utvideo.UpdateIni]
system.ini, drivers32,,"VIDC.ULRA=utvid903.dll"
system.ini, drivers32,,"VIDC.ULRG=utvid903.dll"
system.ini, drivers32,,"VIDC.ULY0=utvid903.dll"
system.ini, drivers32,,"VIDC.ULY2=utvid903.dll"

[utvideo.UpdateIni.Del]
system.ini, drivers32,,"VIDC.ULRA=utvid903.dll"
system.ini, drivers32,,"VIDC.ULRG=utvid903.dll"
system.ini, drivers32,,"VIDC.ULY0=utvid903.dll"
system.ini, drivers32,,"VIDC.ULY2=utvid903.dll"

[utvideo.AddReg]
HKLM,Software\Microsoft\Windows NT\CurrentVersion\Drivers32,VIDC.ULRA,,"utvid903.dll"
HKLM,Software\Microsoft\Windows NT\CurrentVersion\Drivers32,VIDC.ULRG,,"utvid903.dll"
HKLM,Software\Microsoft\Windows NT\CurrentVersion\Drivers32,VIDC.ULY0,,"utvid903.dll"
HKLM,Software\Microsoft\Windows NT\CurrentVersion\Drivers32,VIDC.ULY2,,"utvid903.dll"

HKLM,Software\Microsoft\Windows\CurrentVersion\Uninstall\utvideo
HKLM,Software\Microsoft\Windows\CurrentVersion\Uninstall\utvideo,DisplayName,,"UT Video Codec Suite 9.0.3 (Remove Only)"
HKLM,Software\Microsoft\Windows\CurrentVersion\Uninstall\utvideo,UninstallString,,"rundll32.exe setupapi.dll,InstallHinfSection DefaultUninstall 132 %17%\utvid903.inf"

For a Win32 machine, just right-click, install, enjoy ;)

Boolsheet
7th September 2011, 01:50
If you haven't seen it yet, JoeH had similar problems. Here's the post (http://forum.doom9.org/showthread.php?p=1396348#post1396348) where he describes how he could fix it.

You can also extract msi packages with:
msiexec /a c:\utvideo-9.0.3-x86.msi /qb TARGETDIR=c:\utvideo_9.0.3\

mempf
9th September 2011, 14:15
Hey, great work with the UT codec. However I am sad to report there seems to be a problem when Adobe CS5.5 Products like Media Encoder and Premiere.

When version 8.5 or newer is installed I often get random crashes at specific points in the video when using files as input into CS5.5. When using version 8.4 I have no problems what so ever.

Other players and encoders have no problem at all processing the exact same video and no crash occurs at the place it crashes in CS5.5. Even if I get a crash with 8.5 or newer I can uninstall it, reinstall version 8.4 and the crash will be gone. Update to version 8.5 or newer and the crash happens at the exact same place again.

Other people seem to have the same issue. http://forums.adobe.com/message/3839496 and http://forums.adobe.com/thread/885188 seem to document the issue as it occurs for me. For these people both the Lagarith codec and UT crashes in similar ways, I too have found this to be the case. Also with Lagarith reverting to an earlier version seems to fix the problems.

As mentioned rolling back to version 8.4 seems to resolve the problem at the cost of all improvements since 8.4. The most up to date UT codec version 9.0.3 seems to also crash CS5.5 in the exact same way so the problem is still ongoing.

These crashes only occur when when UT is the input format. Output format doesn't matter.

I'd be happy to provide any other information that may be needed to help debug this problem.

Thanks for making such a great codec and I hope this helps make it even better.

mp3dom
10th September 2011, 15:57
Thanks, resolved. It was a registry key referring to the old utvideo.dll Changing to utv_vcm.dll fixed the issue for both x86 and x64.

Chikuzen
10th September 2011, 16:00
@mempf

a request from author to you .
please upload a small sample clip that cause crash with CS5.5.

mempf
10th September 2011, 22:53
@mempf

a request from author to you .
please upload a small sample clip that cause crash with CS5.5.

I will try however, the nature of the problem is such that this is near impossible to do.

If I use just the section of a video that crashes, often the crash will be gone. The problem seems to occur most often with long big files.

This said I will try my best to create a clip which has the problem but is also short. This may take a while.

UPDATE:

I have had no luck in isolating a clip which causes the problem/crash. Every time I cut a section of the video which will cause a crash out, it will no longer cause a crash. I guess the length of the file and what comes after the problem spot is important. I will keep trying but I do not expect success. The other problem is that only video files of around 100GB seem to cause the crashes. This makes it very difficult/impossible to send a sample of the video.

Reproducing the problem shouldn't be harder than converting a long (like hour long) HD video to UT and then trying to have Adobe CS5.5 process or playback that file. I apologize for being unable to suggest anything else to replicate at this time.

Midzuki
11th September 2011, 14:07
As a suggestion to the author of the codec: use IExpress instead of the pesky :p MSI installer. Below is a sample SED file for the version 8.5.2 of UT Video:

[Version]
Class=IEXPRESS
SEDVersion=3
[Options]
PackagePurpose=InstallApp
ShowInstallProgramWindow=0
HideExtractAnimation=0
UseLongFileName=0
InsideCompressed=0
CAB_FixedSize=0
CAB_ResvCodeSigning=0
RebootMode=N
InstallPrompt=%InstallPrompt%
DisplayLicense=%DisplayLicense%
FinishMessage=%FinishMessage%
TargetName=%TargetName%
FriendlyName=%FriendlyName%
AppLaunched=%AppLaunched%
PostInstallCmd=%PostInstallCmd%
AdminQuietInstCmd=%AdminQuietInstCmd%
UserQuietInstCmd=%UserQuietInstCmd%
SourceFiles=SourceFiles
[Strings]
InstallPrompt=
DisplayLicense=
FinishMessage=UT Lossless Video Codec 8.5.2 has been installed successfully.
TargetName=C:\INSTALLS.DIR\UTVID852\utvideo-8.5.2-setup.exe
FriendlyName=UT Lossless Video Codec 8.5.2
AppLaunched=utvid852.inf
PostInstallCmd=<None>
AdminQuietInstCmd=
UserQuietInstCmd=
FILE0="utvcm852.dll"
FILE1="utvideo.dll"
FILE2="utvid852.inf"
[SourceFiles]
SourceFiles0=C:\INSTALLS.DIR\UTVID852\
[SourceFiles0]
%FILE0%=
%FILE1%=
%FILE2%=

Mr_Khyron
11th September 2011, 18:12
Version 10.0.1

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

Bug fixes:
(Windows) If "Save configuration globally by codec itself" in "Global Configuration" is checked, codec crashes at initialization.

Others:
(Mac) Changed base SDK from 10.6 to 10.5


10.0.0
New features:
Add QuickTime components for Mac OS X. Decoding to RGB24/ARGB32 are supported. Very slow.

Others:
Input/output format checking is more accurate.

Boolsheet
12th September 2011, 06:42
Aw, version 10.0.0 runs into a pure virtual call for me.
It calls GetTinyName in the constructors of CULY0Codec and CUL00Codec.

0027e450 5b36354e utv_core!_purecall+0x25 [f:\dd\vctools\crt_bld\self_x86\crt\src\purevirt.c @ 54]
0027e4cc 5b363190 utv_core!CUL00Codec::LoadConfig+0x7e [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_core\ul00codec.cpp @ 88]
0027e530 5b367b78 utv_core!CUL00Codec::CUL00Codec+0x70 [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_core\ul00codec.cpp @ 17]
0027e58c 5b367d87 utv_core!CULY0Codec::CULY0Codec+0x18 [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_core\uly0codec.cpp @ 37]
0027e5fc 5b358ae8 utv_core!CULY0Codec::CreateInstance+0x47 [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_core\uly0codec.cpp @ 46]
*** WARNING: Unable to verify checksum for C:\Windows\SysWOW64\utv_vcm.dll
0027e768 5b41998b utv_core!CCodec::CreateInstance+0x88 [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_core\codec.cpp @ 67]
0027e978 5b419dd3 utv_vcm!CVCMCodec::CVCMCodec+0x9b [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_vcm\vcmcodec.cpp @ 18]
0027ea94 5b4194ea utv_vcm!CVCMCodec::Open+0xd3 [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_vcm\vcmcodec.cpp @ 51]
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\MSVFW32.dll -
0027eb94 5c7d18f6 utv_vcm!DriverProc+0x14a [e:\utvideo-10.0.0-src\utvideo-10.0.0\utv_vcm\driverproc.cpp @ 27]
WARNING: Stack unwind information not available. Following frames may be wrong.
0027ebb8 5c7d3abe MSVFW32!ICSendMessage+0x31
*** WARNING: Unable to verify checksum for C:\Windows\SysWOW64\AviSynth.dll
*** ERROR: Symbol file could not be found. Defaulted to export symbols for C:\Windows\SysWOW64\AviSynth.dll -
0027ee40 100a58d9 MSVFW32!ICOpen+0xe9
0027ee58 100a5dc5 AviSynth!DllCanUnloadNow+0x8ff49
0027ef24 774e125a AviSynth!DllCanUnloadNow+0x90435
[...]

Does it work for other people?

Edit: Version 10.0.1 was released and fixed the issue.

SirLagsalot
24th September 2011, 01:29
Other people seem to have the same issue. http://forums.adobe.com/message/3839496 and http://forums.adobe.com/thread/885188 seem to document the issue as it occurs for me. For these people both the Lagarith codec and UT crashes in similar ways, I too have found this to be the case. Also with Lagarith reverting to an earlier version seems to fix the problems.


The Lagarith crash was caused by a 1-byte overrun when reading the compressed data. Adobe apparently allocates EXACTLY the minimum size necessary for the compressed frame, so read overruns will cause crashes if the overrun happens to cross a page boundary. Since the UT crash seems to be similar, I would look for potential read overruns in the decoder.

Chikuzen
6th October 2011, 06:31
Version 10.0.2

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.2-readme.en.html) / installer for Windows (32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.2-win-x86.msi))(64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.2-win-x64.msi)) / zip for MacOSX (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.2-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.2-src.zip)

Bug fix
(Windows) Decoder rarely cashes.

nhope
14th October 2011, 18:41
I am getting crashing when putting Ut-encoded clips on the Sony Vegas Pro timeline. Everything was OK in Ut 9.0.3. Now in both 10.0.1 and 10.0.2 I get this:

Vegas Pro 8.0c 32-bit on XP SP3 laptop - OK
Vegas Pro 10.0e 32-bit on XP SP3 laptop -CRASH
Vegas Pro 8.0c 32-bit on XP x64 SP2 desktop - CRASH
Vegas Pro 10.0e 32-bit on x64 SP2 desktop - CRASH

So I've rolled back to 9.0.3.

I haven't tried the 64-bit version of Vegas or Ut.

Chikuzen
16th October 2011, 17:00
Version 10.0.3

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.3-readme.en.html) / installer for Windows (32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.3-win-x86.msi))(64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.3-win-x64.msi)) / zip for MacOSX (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.3-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.0.3-src.zip)

Bug fix
 (Windows) Did not check width and height of input/output equal.
Others
 Add GNUmakefile to compile/use libutvideo under POSIX environments (patched by Derek Buitenhuis).

see also this (http://www.ffmpeg.org/trac/ffmpeg/ticket/534).

Chikuzen
19th October 2011, 11:59
Kostya Shishkov(a libav developper) wrote UtVideo decoder, and it has commited to libav's official repository.
http://git.libav.org/?p=libav.git;a=commit;h=0d8506b8c52659c5bfff9535391d5e95ddcd45f1

now, we can use UtVideo on most of platform :D

Yellow_
19th October 2011, 13:42
That's most excellent news. Are there any comparisons done between lossless h264 and utcodec as an intermediate format? Apart from ut being 8bit only?

Chikuzen
19th October 2011, 14:16
That's most excellent news. Are there any comparisons done between lossless h264 and utcodec as an intermediate format? Apart from ut being 8bit only?

comparison
http://forum.doom9.org/showthread.php?t=158420

note:
atm, libavcodec has no SIMD codes for decoding of UtVideo.
Thus, its decoding speed is slower than original VCM.
I head that Ronald is gonna implement them on #libav-devel@freenode.

Chikuzen
26th October 2011, 12:21
Version 10.1.0

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.1.0-readme.en.html) / installer for Windows (32bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.1.0-win-x86.msi))(64bit (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.1.0-win-x64.msi)) / zip for MacOSX (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.1.0-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.1.0-src.zip)

Performance Improvements
 (Mac) Support multithreading.
Others
 Add mingw environment supports to compile/use libutvideo (require Microsoft Windows SDK).

Midzuki
1st December 2011, 06:50
Performance Improvements
(Mac) Add assembly language version routine. Now as fast as Windows version.

videohelp.com/tools/Ut-Video-Codec-Suite (http://www.videohelp.com/tools/Ut-Video-Codec-Suite) :)

qyot27
3rd December 2011, 22:18
I'm having an issue getting libutvideo to link into FFmpeg (and with 10.2.0, is it even necessary to have the MS SDK now? It compiled without it so long as I used MinGW-w64, and I got the same errors below even if I did include it). The last error it gives in config.log is this:
i686-w64-mingw32-g++ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -U__STRICT_ANSI__ -march=pentium3 -mtune=pentium3
-DPTW32_STATIC_LIB -march=pentium3 -std=c99 -fno-common -fomit-frame-pointer -D__STDC_CONSTANT_MACROS -c -o /tmp/ffconf.2JHozCfc.o
/tmp/ffconf.Bi8ZUFTw.cpp
cc1plus: warning: command line option '-std=c99' is valid for C/ObjC but not for C++ [enabled by default]
In file included from /tmp/ffconf.Bi8ZUFTw.cpp:4:0:
/usr/lib/gcc/i686-w64-mingw32/4.6.1/../../../../i686-w64-mingw32/include/utvideo/Codec.h:31:10: error: 'INT_PTR' does not name a type
/usr/lib/gcc/i686-w64-mingw32/4.6.1/../../../../i686-w64-mingw32/include/utvideo/Codec.h:32:10: error: 'INT_PTR' does not name a type
ERROR: utvideo not found
Is there some option I need to pass to resolve that? A Google search for INT_PTR errors didn't really turn up anything, or seemed to lean toward needing to amend the code itself to fix.

The libutvideo compile log, since it had some warnings and I'm not sure if those point to any other specific problem:
$ make CROSS_PREFIX=i686-w64-mingw32-
CXX utv_core/Codec.o
In file included from utv_core/Codec.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/Convert.o
In file included from utv_core/Convert.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/DummyCodec.o
In file included from utv_core/DummyCodec.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/Format.o
In file included from utv_core/Format.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/FrameBuffer.o
In file included from utv_core/FrameBuffer.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/GlobalConfig.o
In file included from utv_core/GlobalConfig.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/HuffmanCode.o
CXX utv_core/Predict.o
In file included from utv_core/Predict.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/Thread.o
CXX utv_core/TunedFunc.o
CXX utv_core/UL00Codec.o
In file included from utv_core/UL00Codec.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/ULRACodec.o
In file included from utv_core/ULRACodec.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/ULRGCodec.o
In file included from utv_core/ULRGCodec.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/ULY0Codec.o
In file included from utv_core/ULY0Codec.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/ULY2Codec.o
In file included from utv_core/ULY2Codec.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
CXX utv_core/utv_core.o
In file included from utv_core/utv_core.cpp:5:0:
utv_core/utvideo.h:50:0: warning: "__i386__" redefined [enabled by default]
<built-in>:0:0: note: this is the location of the previous definition
AR utv_core/libutvideo.a
RANLIB utv_core/libutvideo.a

The same problem with linking to FFmpeg occurred on a regular MSys/MinGW-w64 environment as well, not just on attempting to cross-compile under Linux.

smok3
3rd December 2011, 23:58
1. should ffmpeg -vcodec copy work as a rewraper for ut.avi to ut.mov?
2. how do i register utvideo.component with lion/osx? (just coping to /System/Library/QuickTime or /Users/me/Library/QuickTime did not do the trick)

qyot27
6th December 2011, 18:22
Never mind, I got the FFmpeg linking issue sorted out. It required stopping GlobalConfig.o from being linked in, commenting out all the #ifdef _WIN32 sections with INT_PTR instances in the source in utv_core/, and the (probably unrelated) redefinition warnings were resolved by editing utv_core/utvideo.h so that the sections with:
#define _WIN64_X64
#define __x86_64__
#define _WIN32_X86
#define __i386__
are defined together,
#define _WIN64_X64 __x86_64__
#define _WIN32_X86 __i386__



I'm positive there's a more elegant solution to doing all of that, but it allowed FFmpeg to link to libutvideo when both are built by MinGW and the target is 32-bit (I don't have access to 64-bit Windows; maybe it breaks something there). I also built FFMS2, of which Ut Video decoding works so long as it's stored in AVI - from what I can tell, it is using libutvideo, since I used '--disable-decoder=utvideo --enable-libutvideo' while compiling FFmpeg.

kypec
7th December 2011, 14:50
@qyot27: your achievements seem promising - any chance of implementing UtVideo decoding directly into x264? I mean x264 can be compiled with FFMS support currently, so this shouldn't be a problem... or am I missing something?
This would be awesome improvement and I could eliminate one step where I need to create dumb AVS script for each source file that is fed to x264, containing simply AVISource("some_utvideo_file.avi")

nm
7th December 2011, 15:33
@qyot27: your achievements seem promising - any chance of implementing UtVideo decoding directly into x264? I mean x264 can be compiled with FFMS support currently, so this shouldn't be a problem... or am I missing something?

You are missing the Ut Video decoder in FFmpeg and libav (http://patchwork.libav.org/patch/10425/). FFmpeg also supports decoding with an external Ut Video library.

But I don't know if any of the x264+FFMS binaries include it yet. Have you tried latest builds?

qyot27
7th December 2011, 22:09
@qyot27: your achievements seem promising - chance of implementing UtVideo decoding directly into x264? I mean x264 can be compiled with FFMS support currently, so this shouldn't be a problem... or am I missing something?
This would be awesome improvement and I could eliminate one step where I need to create dumb AVS script for each source file that is fed to x264, containing simply AVISource("some_utvideo_file.avi")
You are missing the Ut Video decoder in FFmpeg and libav (http://patchwork.libav.org/patch/10425/). FFmpeg also supports decoding with an external Ut Video library.

But I don't know if any of the x264+FFMS binaries include it yet. Have you tried latest builds?
Precisely. The ability for x264 to decode Ut Video through LAVF/FFMS2 has been there since the internal decoder was committed back in October. Any LAVF/FFMS2-bearing x264 that was built against a version of libavcodec newer than October 20th will have the internal utvideo decoder available. The external decoder (libutvideo) is what needs the fixes I noted above, but that's not entirely true either - those fixes are needed for building under MinGW only. For native Linux and Cygwin builds, that's not necessary.

Why use the external decoder instead of the internal one? Because you can, and if there's any kind of feature disparity that gets introduced the external decoder will have those changes first, seeing as how it's the format's reference implementation (although for all I know, new features would still have to be made accessible through the FFmpeg-side wrapper anyway for the library to be able to deal with it). I won't say anything about speed tests I did because my CPU doesn't have SSE2 and that would skew the results, but if the internal decoder hasn't been optimized in that way (and the assembly opts still apply to the external decoder when built with MinGW), then the external decoder could possibly be a lot faster.

poisondeathray
7th December 2011, 22:23
Do you know if there are plans for UT Video encoding on the FFmpeg side ?

qyot27
7th December 2011, 22:38
Do you know if there are plans for UT Video encoding on the FFmpeg side ?
According to some of the IRC logs, encoding is 'ready', but I wouldn't know how much has to be resolved before it gets committed.

poisondeathray
7th December 2011, 22:39
According to some of the IRC logs, encoding is 'ready', but I wouldn't know how much has to be resolved before it gets committed.

Thanks :)

kypec
8th December 2011, 11:00
Yeah, silly me - I confirm that feeding latest x264 r2120 (unpatched komisar's build (http://komisar.gin.by/)) with UtVideo AVI file works fine.
Decoding performance is even slightly better than that of AVISource() I'd say because I achieved higher encoding speed in first pass:
82.39 fps @ direct AVI file feed -vs- 71.12 fps @ Avisynth AVISource() feed
Used x264 64-bit on Intel E8400, Win 7 x64

infinityloop
13th December 2011, 20:07
I am using dxtory to capture pc gameplay.
one guy from the libav recommend the UT Video Codec to use for encoding.

So I installed utvideo-10.2.0-win-x86.msi

And I have 2 issues:

CPU: core i7 2600
OS: Windows 7 64bit

1. CPU load
When capturing 1080p30 with RGB lossless or yuv422 - CPU load increases by 15% which is okay.
But with yuv420 cpu load increases by 38% !

2. Files are not working in Adobe Premiere CS5.5
When I import files encoded with UT Video Codec (RGB, or YUV420 or YUV422) all I get is black. Audio plays fine. Premiere can tell me the codec used in this video, but it wont display any picture.

Keiyakusha
13th December 2011, 20:38
Premiere CS5 and up is a pure 64bit software, 32bit support was dropped. So no wonder utvideo-10.2.0-win-x86.msi doesn't works with it, you shouldn't be using it to begin with. You should have everything 64bit or everything 32bit.

smok3
13th December 2011, 20:53
Premiere CS5 and up is a pure 64bit software, 32bit support was dropped

On previous workstation (64bit win7) i just installed both (32bit for virtualdub and 64bit for premiere and there were no obvious problems).

Keiyakusha
13th December 2011, 20:57
On previous workstation (64bit win7) i just installed both (32bit for virtualdub and 64bit for premiere and there were no obvious problems).
Well good for you. But how this confirms or refutes the statement you quoted?
- 32bit premiere doesn't exist anymore
- you can't use 32bit libraries, decoders, whatever in 64 bit software or vice versa.
You may be aware of that but infinityloop obviously not taking this into account.

infinityloop
13th December 2011, 22:26
Premiere CS5 and up is a pure 64bit software, 32bit support was dropped. So no wonder utvideo-10.2.0-win-x86.msi doesn't works with it, you shouldn't be using it to begin with. You should have everything 64bit or everything 32bit.
*facepalm*
What I should have done is install the 32 AND 64 bit version of UT Video.

Because you are absolutelly right, Adobe Premiere is now only 64bit (totaly forgotten that *oops*) - but dxtory is a 32bit application, so for encoding, I do need to have the 32bit version installed too.

Beside the too high CPU load for encording/recording YUV420, all is working well now. :)

smok3
13th December 2011, 23:17
Well good for you. But how this confirms or refutes the statement you quoted?
- 32bit premiere doesn't exist anymore
- you can't use 32bit libraries, decoders, whatever in 64 bit software or vice versa.
You may be aware of that but infinityloop obviously not taking this into account.

sorry for not being clear, was just actually pointing out that you may install both versions, which may not be (so) obvious.

infinityloop
14th December 2011, 07:43
sorry for not being clear, was just actually pointing out that you may install both versions, which may not be (so) obvious.
Correct, both (32 and 64 bit versions) installed on the same PC is working nicely, and actually required because not all software you may use the recorded file with is available as 64 bit version. :)

nhope
18th December 2011, 15:20
Version 10.2.1

read me (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.2.1-readme.en.html) / installer for Windows (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.2.1-win.exe) / zip for MacOSX (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.2.1-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.2.1-src.zip)

Version 10.2.1
* (Windows) Installer is now Inno Setup based. Single installer is available for both x86 and x64 windows.

Version 10.2.0
* (Mac) Add assembly language version routine. Now as fast as Windows version.

Version 10.1.0
* (Mac) Support multithreading.

I am on Windows XP x64, and I want to install the 32-bit version of this codec. Unfortunately, because the 32-bit and 64-bit versions are now combined, this latest version only appears to install the 64-bit version. So I am going back to 10.2.0.

Asmodian
19th December 2011, 03:49
I see the x86 and x64 versions using either 32 or 64 bit VirtualDub with the newest installer (10.2.1) on Win7 x64.

infinityloop
19th December 2011, 08:30
Any word on the way too high CPU load for YUV420?

Generates more than 2 times the CPU load of RGB or YUV422.

When capturing 1080p30 with RGB lossless or yuv422 - CPU load increases by 15% which is okay.
But with yuv420 cpu load increases by 38% !

Midzuki
20th December 2011, 10:40
Bug fixes

(Windows) Registration of x86 VCM codec is failed on Vista/XP x64.

Download from:

http://www.videohelp.com/tools/Ut-Video-Codec-Suite

@ the power users :rolleyes:

please update your Inno Setup UNPACKER :devil: ;) :p

http://sourceforge.net/projects/innounp/files/

Midzuki
11th January 2012, 08:15
Version 10.2.3 released

Changelog:
Bug fixes

(Windows) When setting codec configuration to VCM codec object, it returns failure even though it is successful.

Others
(Windows) Add "last-resort" .reg file for install troubleshooting. :rolleyes: :rolleyes: :rolleyes: :rolleyes: :rolleyes:

http://umezawa.dyndns.info/archive/utvideo/

OR...

http://www.videohelp.com/tools/Ut-Video-Codec-Suite