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

[tobinaka]

The following was edited last on 16th November 2009 at 23:16.
To find the latest info, please check newer posts or the author's blog (http://umezawa.dyndns.info/wordpress/?cat=28).

----

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

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


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

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


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

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

Attention

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

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


Its Implementation Goal (from readme file)

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


Achievement (from readme file)

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


Minimum Requirement (from readme file)

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



Download

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


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

[squid_80]

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

[tobinaka]

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

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


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


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

His test enviloment

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

Codecs

-Ut Video Codec Suite 4.0.2 (not 5.1.0 of today. 4.0.2 didn't have YUV420 mode)
-Huffyuv (http://neuron2.net/www.math.berkeley.edu/benrg/huffyuv.html) 2.1.1
-Huffyuv_mt (http://www29.atwiki.jp/lossless/pages/11.html) >>712
-YUY2 Lossless Codec (YLC) (http://ruriruri.zone.ne.jp/aviutl/) 0.25
-Lagarith (http://lags.leetcode.net/codec.html) 1.3.16
-FastCodec 1.0beta (http://videosoft.org/codecs/fastcodec/)
-Arithyuv 1.1.1
-MSU Lossless Video Codec (http://www.compression.ru/video/ls-codec/index_en.html) 0.6.0

YLC is a YUY2 Lossless Codec (requires SSE) developed by KEN-kun a Japanese programmer who has made AviUtl. You can download YLC from his site (http://spring-fragrance.mints.ne.jp/aviutl/) (Japanese).

The results

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

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

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


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

[Lugia25000]

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

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

Thanks. :)

[TEB]

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

[video_magic]

Very, very interesting for me.

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

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

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

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

[tobinaka]

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

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

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

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

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

Your comments must drive him to improve the codec suite!

[LoRd_MuldeR]

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

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

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

;)

[squid_80]

squid_80, I have a question for you. What CPU did you use for the test? I must have noted that the developer UMEZAWA has only INTEL Conroe-based processer, then he can't test on AMD (especially Athlon and Turion), Core i7 and so on. I would seem that Ut Video Codec's performance depends on the CPU architectures.
I was testing on a Core2 Q6600@2.4GHz B0 stepping, 8GB ram, windows XP64. I have another box with a Core2 E6600 but no AMD based machines. The codec seems to mainly use SSE2 assembly, I know Athlon64's perform very poorly with SSE2 but don't know about Phenoms since I've never had one. Penryn and i7s normally get a big boost with lossless codecs (prediction+entropy based) since they love big data caches.

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

[tobinaka]

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

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

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

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

;)

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

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

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

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

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

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

[tobinaka]

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

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

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


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

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


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

We look forward to your continued support. Thanks!

[Lugia25000]

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



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

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

I hope Takeshi UMEZAWA can fix it.

Sorry my english is not so good.

[Dark Shikari]

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

[LoRd_MuldeR]

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

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

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

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

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

[Leak]

UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically (though he uses MMX at a single part :p)
Maybe he got confused by the topic Avery discusses here (http://www.virtualdub.org/blog/pivot/entry.php?id=107)?

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

[squid_80]

UMEZAWA is concerned that it will be all C++ on x64 version compiling with doing nothing special. It's OK?
I think what you mean is if I compile a x64 version all the assembly code will be left out? No, I can modify the assembly so it runs under x64.

UMEZAWA also says that he develops Ut Video for post-P4 CPU. He won't write MMX code even if MMX is faster because MMX is doomed -- 64bit Windows couldn't use MMX practically (though he uses MMX at a single part )If that's what he wants then fair enough. Since the code is GPL there's no reason to pressure the author to add something he doesn't want to.

Also why should MMX not work under 64-Bit Windows? I never heard anything like that before.I wish I were as fortunate as you. My first few posts (http://forum.doom9.org/showthread.php?p=583368#post583368) on this forum (and a few other forums) were spent trying to explain this. Eventually it became the accepted opinion (probably Avery's blogpost helped, as did clarification added to Agner Fog's Calling Convention doc) and these days we think someone is crazy if they say MMX can't be used in windows 64-bit code.

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

[tobinaka]

UMEZAWA's Japanese blog (http://umezawa.dyndns.info/wordpress/) updated, and the known problem was listed. I added them my first post on this threads, too.

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

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

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

I hope Takeshi UMEZAWA can fix it.

Sorry my english is not so good.

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

[tobinaka]

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

Huh? This statement is nonsensical.

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


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

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

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

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

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


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

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

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

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

[tobinaka]

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

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

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

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

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

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

[easy2Bcheesy]

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

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

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

[tobinaka]

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

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

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

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

[Lugia25000]

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


Thanks. :)


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

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

The installer works fine on my WinXP Sp3.

[easy2Bcheesy]

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

[tobinaka]

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

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

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

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

[tobinaka]

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

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

[easy2Bcheesy]

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

[tobinaka]

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

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

[easy2Bcheesy]

Yes, joy would be the right word.

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

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

[Lugia25000]

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

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

[easy2Bcheesy]

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

[tobinaka]

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

How fast you are...

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

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

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

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

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

[tobinaka]

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

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

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

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

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

[tobinaka]

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

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

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

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

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

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

[turbojet]

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

Here's the results

ENCODE DECODE TOTAL SIZE(MB)

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

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

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

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

x264 1:05 1:41 2:46 523

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

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



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

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

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

[tobinaka]

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


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

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

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

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


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

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

[turbojet]

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

[tobinaka]

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

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

[easy2Bcheesy]

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

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

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

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

[tobinaka]

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

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

[johnsonlam]

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

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

Hope UT will be even better.

[easy2Bcheesy]

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

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

[tobinaka]

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

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

[easy2Bcheesy]

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

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

Is higher compression ratio possible?

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

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

[johnsonlam]

Is higher compression ratio possible?


Sorry for breaking in.

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

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

[easy2Bcheesy]

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

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

[tobinaka]

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

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

[Dark Shikari]

Sorry for breaking in.

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

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

[Tommy Carrot]

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

[Dark Shikari]

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

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

[tobinaka]

Ut Video ver 5.2.2 has come today.

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

5.2.1 and 5.2.2 are for fixes.

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

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

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

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

[easy2Bcheesy]

Hi, please let me know when my suggestion is included!

[easy2Bcheesy]

Hi, please let me know when my suggestion is included!

[vsv]

Ask same as easy2Bcheesy ;)

[easy2Bcheesy]

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]

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]

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]

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]

version 5.2.3　available.

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

[tobinaka]

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]

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ï]

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]

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]

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]

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]

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]

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ï]

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]

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]

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]

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]

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ï]

INF installer for revision 6.0.2 (http://www.megaupload.com/?d=6COBN0VD) :)

[tobinaka]

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]

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]

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]

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]

A 64 bit version, exactly what I needed! And it works perfectly.

:thanks:

[Midzuki]

INF installer for version 7.0.0 (x86):

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

[Leeloo Minaï]

Midzuki : you missed to remove the version number of the dll name in the section :
[SourceDisksFiles]
utvideo.inf=1
utvideo602.dll=1

[Midzuki]

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]

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]

@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]

Thanks for the updated info, Chikuzen. :)

-Jeff

[JeffBDVS]

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]

@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]

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]

Thanks. I'll give it a try and post back.

-Jeff

[JeffBDVS]

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]

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]

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]

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]

@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]

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]

@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]

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]

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]

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]

@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 Ｗindows7 have something different from the other countries?

[JoeH]

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]

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]

@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]

x64.

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

[JeffBDVS]

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]

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]

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]

[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]

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]

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]

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]

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]

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]

@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]

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]

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ï]

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]

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]

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]

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ï]

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]

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]

VFW codecs aren't installed by registering them.

[Midzuki]

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]

OK, thanks for clearing that up. So, it's not a regsvr incompatibility then anyway.

[Boolsheet]

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]

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]

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]

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]

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ï]

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]

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]

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]

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]

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]

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]

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]

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]

Sweet! Awesome update!

[Mr_Khyron]

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]

@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]

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

:eek: :)

Many :thanks:

[Chikuzen]

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_]

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]

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_]

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]

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]

Simply magic...

ARIGATÔ GOZAIMASU !!!

( :thanks: )

[Mr_Khyron]

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]

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]

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]

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]

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

[_gl]

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

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

[johnsonlam]

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

Thank you very much for the improvement!

subarashi! hondo ni arigato gozaimasu!

[yup]

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

[GoodzMastaJ]

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

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

[nm]

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

[...]

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

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

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

[kypec]

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

[jmac698]

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

[ChiDragon]

version 8.3.0

[...]

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

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

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

[Chikuzen]

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

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

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

[zcream]

@Chikuzen san

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

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

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

Thanks!

[zcream]

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

[JeffBDVS]

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

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

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

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

Thank you,
-Jeff

[Boolsheet]

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

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

[JeffBDVS]

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

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

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

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

Thanks,
-Jeff

[kolak]

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

Andrew

[Chikuzen]

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

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


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

[Boolsheet]

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

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


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

[Chikuzen]

oops :eek:, please wait.

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

[JeffBDVS]

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

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

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

-Jeff

[Chikuzen]

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

[kolak]

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


Andrew

[JeffBDVS]

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

-Jeff

[JeffBDVS]

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

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

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

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

-Jeff

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

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

[Boolsheet]

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

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

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

[JeffBDVS]

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

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

-Jeff

[Boolsheet]

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

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

[JeffBDVS]

More testing/troubleshooting:

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

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

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

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

-Jeff

[kolak]

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


Andrew

[Mr_Khyron]

version 8.5.1

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

Bux fixes

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

Others

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

[Chikuzen]

version 8.5.2

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

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

[Fullmetal Encoder]

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

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

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

[Mr_Khyron]

version 9.0.0

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

New features
- Add DMO decoder.

[kypec]

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

[Chikuzen]

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

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

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

[yup]

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

[kypec]

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

[yup]

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

[kypec]

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

[Chikuzen]

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

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

[yup]

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

[Chikuzen]

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

GraphEdit

[yup]

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

[Chikuzen]

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

[yup]

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

[Chikuzen]

@Chikuzen!
Your version Avisynth?

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

[yup]

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

[3ds]

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

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

normal?

[Chikuzen]

normal?

There is a possibility though it is a special case.

[3ds]

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

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

in RGB:
Lagarith - 518MB
Ut - 517MB

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

[JoeH]

Lagarith generally compresses a little more, but UT is much, much, much faster than Lagarith, both at encoding and especially at decoding.

[Chikuzen]

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]

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]

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]

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]

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]

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_]

q1: yes

[smok3]

q3: is there a mac version?

[mp3dom]

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]

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]

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]

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]

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]

@mempf

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

[mempf]

@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]

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]

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]

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]

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]

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]

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]

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]

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_]

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]

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]

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]

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]

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]

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]

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]

@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]

@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]

@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]

Do you know if there are plans for UT Video encoding on the FFmpeg side ?

[qyot27]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[kolak]

Can we have 10bit version with v210 pin output and 8bit pin with optional dithering (ordered+noise). Thank you - hehe :)

Latest ffmbc opened bitrate/quantizer in ProRes encoder and with q=1 it goes almost lossless- don't think it's 100% lossless, but PSNR is around 90dB (450Mbit average bitrate, HD, 24p)

[Midzuki]

Version 10.2.4 has been released

Changelog:

(Windows) Installer now displays "before-install" notice.

(Mac) Report more apropreate codec name to QuickTime.

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

OR

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

[smok3]

still waiting for that magic few words on where to drop stuff on osx....

edit: p.s. is anybody working on ffmpeg encoder as well? (the decoding seems to be working fine)

[mp3dom]

+1 for 10bit (it would be fantastic!). ProRes is lossy and uncompressed is extremely huge in filesize. A lossless 10bit codec would be great for original backup/archive.

[SubOne]

I have a newbie question... If the source is 12-bit then is 8-bit UT really lossless? If 12-bit is 0-4096 and 8-bit is 0-256, then 16 in 8-bit = 256 in 12-bit, and 17 in 8-bit = 272 in 12-bit. So what happens if a channel is at level 260 in the 12-bit source? It should be 16.2 in 8-bit but since that is not possible does it get approximated to 16 in 8-bit and thus loses accuracy? Or is there some other mojo going on that ensures UT is actually lossless even at 8-bit? Hope I am making sense at all...

By the way, X264 10-bit works great, but it's not as fast.

[kolak]

UT is lossless only at 8bit.

[kolak]

+1 for 10bit (it would be fantastic!). ProRes is lossy and uncompressed is extremely huge in filesize. A lossless 10bit codec would be great for original backup/archive.

ffmbc has open ProRes, so you can have 99.9% lossless encoding at around 500Mbit.

[yup]

Hi all!
11.0 released
http://umezawa.dyndns.info/archive/utvideo/
yup.

[_gl]

Been using UT for a while and it rocks.

But I would kill (well maybe not kill) for a 4:4:4 YUV flavour (8bit or 10 bit).

I sometimes need to do an intermediate render in Premiere. I only use YUV effects so the entire Premiere pipe is YUV up to the output codec. So if I want it to be truly lossless, 4:4:4 YUV is the only option. Rendering to 4:2:2 (or lower) drops the chroma resolution, and rendering to RGB 8bit causes gradient damage due to the unwanted expansion from studio to PC levels (as well as the YUV->RGB conversion).

I tried using the 4:4:4 mode of HNxHD via Quicktime, but that introduces an unwanted gamma and colour shift (maybe due to Premiere incorrectly using BT601 instead of BT709 for my HD footage). So right now I'm stuck using RGB 8bit lossless (UT or Lagarith).

[SubOne]

Gamma shift is a "feature" of Quicktime/MOV. As with everything Apple, there are no bugs, only features... Plus DNx is lossy.

We really need a 10-bit lossless codec though, yes.

[_gl]

Gamma shift is a "feature" of Quicktime/MOV. As with everything Apple, there are no bugs, only features...

Well, useless then. But the extra colour shift seems to be Premiere using the wrong matrix - or is that also a known Quicktime issue?

Plus DNx is lossy.

Sure, but studio 4:4:4 is sometimes more important to me.

We really need a 10-bit lossless codec though, yes.

Ideally yeah. In Premiere you at least have the option of v210 (uncompressed 10bit 4:2:2), but no 4:4:4 YUV options at all.

[qyot27]

*cough* FFV1 already supports it *cough* (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1eabd71c2bed13648643433249386f4b965b5c14) (it's had YUV420P10 and YUV422P10 support since May 2011)


If the underlying video is 4:2:0, then 4:4:4 rendering isn't lossless to start with. And unless Premiere can handle 4:4:4 exporting internally (and especially at higher bit depths), it'll always be doing some sort of lossy conversion before the final output render. There's a lot more involved in the situation than just making sure the export or import codecs support 10-bit 4:4:4.

[_gl]

If the underlying video is 4:2:0, then 4:4:4 rendering isn't lossless to start with.

Combinations of processing (grading, sharpening etc) and/or overlaying graphics (logos, gradients etc) can create 4:4:4 detail from 4:2:0 etc. source footage.

And unless Premiere can handle 4:4:4 exporting internally

I'm pretty sure it can, it didn't loose chroma when I tested rendering to DNxHD 4:4:4, and Premiere's internal YUV pipe is actually 4:4:4. Of course it has to be tested for AVI specifically, but there's a good chance it's supported.

[SubOne]

The underlying acquisition footage is RGB 4:4:4, hence the requirement for a 4:4:4 lossless codec. Premiere can definitely export 4:4:4, as evidenced from testing each channel from likes of Uncompressed, DPX or DNx 444.

[Mr_Khyron]

Version 11.1.0

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


Performance Improvements

(Mac) Add assembly language version of colorspace conversion routine from RGB to ULY2.
Common: Speed up decoding a little.
Common: Speed up encoding on x64 about 10%

Others

(Mac) encoded size becomes a little smaller by omitting unnecessary media sample flags.

[johnsonlam]

Version 11.1.0
(Mac) Add assembly language version of colorspace conversion routine from RGB to ULY2.
Common: Speed up decoding a little.
Common: Speed up encoding on x64 about 10%
Others
(Mac) encoded size becomes a little smaller by omitting unnecessary media sample flags.

I fail to find the Win 64bit binary, can somebody kindly tell me where?

[the_weirdo]

I fail to find the Win 64bit binary, can somebody kindly tell me where?

The installer will now install both 32-bit and 64-bit version of UtVideo on Windows 64-bit.

[infinityloop]

The installer will now install both 32-bit and 64-bit version of UtVideo on Windows 64-bit.
I'd like to add that 32-bit versions are also required under W7-64 bit, because a 32bit editing or player application can not use the 64-bit codec. :)

[johnsonlam]

I'd like to add that 32-bit versions are also required under W7-64 bit, because a 32bit editing or player application can not use the 64-bit codec. :)

Thanks.
If Umezawa can write down (32 and 64bit) should avoid confusion.

[kypec]

Thanks.
If Umezawa can write down (32 and 64bit) should avoid confusion.
He did write about it (http://umezawa.dyndns.info/archive/utvideo/utvideo-10.2.1-readme.en.html) and you can always look it up in the changelog.

[zerowalker]

Can Null Frames be added?
As that is one of the Main reasons i love Lagarith, as it´s just a waste to recompress identical frames.

Or maybe it´s a reason it can´t be used, something in the encoder or how it works?

[Keiyakusha]

Can you show any real example of where can you find identical frames in video? Most of the time even if they look the same, they are different mathematically and cant be replaced by selecting one of them or their average since this is lossless format.
edit: something like 2-3 100% black frames after my just created CG clip ends and before credits start can be it, but i doubt you'll actually save something with this...

[zerowalker]

There is many times where this can be found.
One is Games, let´s say.

You play 60 fps, it records 30 fps, all i fine.
Then you enter some are, and it goes down to 20 fps, then it will have to repeat some frames to make it 30 fps.

Or let´s say you go to a desk and pick up some paper with text, then it will probably be a still frame with the text on the paper.

Get what i mean:)?

Not really a big realistic use, but it´s very useful for not wasting space on digital recordings(mostly games).

For archival stuff, like analogue, it won´t matter at all, as no screen is identical, as long as it doesn´t lag or something.

[Keiyakusha]

You play 60 fps, it records 30 fps, all i fine.
Then you enter some are, and it goes down to 20 fps, then it will have to repeat some frames to make it 30 fps.

Or let´s say you go to a desk and pick up some paper with text, then it will probably be a still frame with the text on the paper.
I'm not convinced. This is may be true with games but then this indicates some problem. In this case you usually want to go for lower graphic settings or upgrading hardware, not compressing badly recorded footage... As for the desk its not true. You probably will be shooting this with camera, means frames wont be the same. They will have different noise pattern and if at least 1 pixel between 2 frames is different, one of them can't be replaced by "duplicate" mark.
Also not sure how UTvideo works, but if not every frame is keyframe I wonder how it will handle absence of the actual frame in the middle of the group of picture. If group will be split, probably it will only hurt compression.
And if compression algorithm is advanced enough, it almost doesn't uses extra bits for compressing almost the same frames. This is what should be improved as much as possible.

[zerowalker]

Don´t get what you mean with lower settings and compressing badly recorded footage.
With recording, i am talking about Dxtory for example.
And yes it´s true that there often is movement, or if it´s some grain effect.

But in some games, it will be a completely still frame, for example a Menu or when you press start etc.
It´s now very common maybe, but it can be very useful, think about 2D games, there it´s very useful, as there isn´t really stuff moving all the time (especially old games).

Now i understand that this isn´t something to strive for as it´s not a miracle to save some frames here and there.
But i was thinking, if the UT system allows it, i can´t see that it´s hard to add (May be wrong).

And if it can be added with ease, then i don´t see any problems. It will be the best of 2 worlds if you get what i mean.

And of course if it is as you say with the keyframes, and there is really no use, then it´s not worth anything.

But i have a Digital movie i made from a gameplay which has some identical frames (it´s from N64, so it´s 20 fps at 30 fps pretty much all the time in reality, if i didn´t speed upp or add stuff).

And there it´s quite a difference between Lagarith with Null Frames and UT, i think there is about 30% size difference.
And in the end of the video there is like 3 frames which are still for 1-2 sec or more, and there the null feature is really showing it´s usefulness.

Okay it was much more:

Lagarith: 961 MB
UT Video Codec RGB: 2.01GB

I compared them in Avisynth and they are identical, so no color conversion was made.

[Keiyakusha]

Don´t get what you mean with lower settings and compressing badly recorded footage.
I probably got wrong the reason why fps drops. I just remembered something like skyrim where you have 60 fps in one location then you go into some house or out of it and woohoo, its 24 fps now!


Lagarith: 961 MB
UT Video Codec RGB: 2.01GB


I'm sure most of that difference is because difference in algorythm, disregarding duplicates. UTvideo doesnt aims to be best compression-wise, decoding speed is important too. That's why lagarith is not so popular now. Even h264 lossless looks more attractive. I havent tried lagarith for a long time but it was really slow compared to haffman's implementations, they was even saying this on front page. I dont doubth that artificially generated footage indeed may have identical frames. I don't mind anything that may improve compression without affecting speed. I just think this particular feature not worth even slightest effort.

Edit: lets better make Umezawa-san add 10bit support. There is no good solutions right now. x264 vfw can be potential solution, but developers (or should i say maintainers?) are not motivated enough. Yes I know that x264 vfw is bad and everyone hate it but for example... i really want to see some working alternative to all those commercial plugins for 1K$ each.

[zerowalker]

Oh, well then you did get a bit wrong impression there. But that is also a case.

Hmm maybe, but when i use it for normal stuff, they are pretty much the same, let´s say Lagarith is 100gb, then UT may be like 110gb or something like that.
And yeah i know many say it´s slow, i myself hasn´t really run into any problems, even on 1920x1200, even less if i use LAV Filter for decoding.
But i guess the normal cpu doesn´t handle the stress to well, as i got 4ghz i5 and it uses about 100% of 2 cores when it´s on high resolutions, and i think it´s only optimized for 2 cores.

[qyot27]

The most recent versions of Lagarith are a lot more speed optimized, although I don't have any definitive numbers. It's better than it was years ago, though. It was enough for me to actually notice it on a computer that's 11 years old, so if it had to do with assembly it was in the SSE or below realm. Most (all?) of Ut's optimizations are in SSE2, as I understand it, and that's why on newer computers it can run circles around HuffYUV.

Maximizing the impact of the null frame filters for normal footage usually means pulling some AviSynth trickery beforehand, as it can level the sources enough to make it worthwhile (for instance, using Dupped (http://forum.doom9.org/showthread.php?t=134930) on it, especially if a smoother's been run on it first). It also probably has more of an effect on animation.

Feasibly, one could test the impact of null frames on a source by encoding it in Lagarith+nulls first, and then transcoding to Ut whilst preserving the nulls (so that only the real frames are being compared). And then compare the null-containing Ut file to a regular Ut encode of the same source. VirtualDub has a 'Preserve empty frames' option that might let you do a transcode from Lagarith to Ut while keeping nulls intact. If not, it can be forced to work by using avi2tc to produce a de-nulled file + timecodes, from which you can convert the de-nulled file to Ut. Nulls barely take up any space, but if you wanted, you could mux the timecodes back in so that it at least plays back at the right speeds. I use the above method for when I want to produce ffvhuff-encoded files with nulls.

[zerowalker]

It didn´t work, it time went with no progression by using that method on UT.

[qyot27]

Since I actually had need to use the null frame tactic again, I actually tested it like I said above.

Source video consists of essentially a slideshow with some fade-in/out transition effects interspersed throughout.
In other words, lots of static frames that could be dropped as nulls to show the difference it can make.

11095 total frames, 29.97fps, 06:10.203 in length

Script:
FFmpegSource2("video.flv",fpsnum=30000,fpsden=1001)
deen("w3d",3,6,8,8,8)
Dupped()

Save as Lagarith with nulls:
VirtualDub 1.9.11, Fast Recompress, Lagarith 1.3.27, Enable Null Frames, single-threaded*, RGB (Default) preserving YV12 colorspace

Convert Lagarith .avi with nulls to Ut Video with nulls by telling VDub to preserve empty frames
VirtualDub 1.9.11, Fast Recompress, Preserve empty frames, Ut Video 11.1.1 YV12, 1 thread*, Predict median

Compare by converting the same Lagarith file to Ut Video, without preserving empty frames
VirtualDub 1.9.11, Fast Recompress, Ut Video 11.1.1 YV12, 1 thread*, Predict median

*only one thread because I was testing this on an old Celeron Coppermine

I didn't test Predict left since it would only inflate the filesizes and if the goal here is to optimize space savings then it doesn't make much sense.

The result:
Lagarith 1.3.27 (with nulls) 251 MB avi2tc detected 3490 nulls out of 11095 total frames
Ut Video 11.1.1 (with nulls) 345 MB avi2tc detected 3490 nulls out of 11095 total frames,
proving that VirtualDub correctly preserved them
Ut Video 11.1.1 (without nulls) 499 MB avi2tc detected 0 nulls, proving that VirtualDub did
not preserve them when 'Preserve empty frames' was unchecked

[Gser]

YCbCr (BT.601) 4:2:0 8bit limitedSo basically it doesn't support BT.709?

[Keiyakusha]

So basically it doesn't support BT.709?
Its not something that have to be "supported"

[kolak]

So basically it doesn't support BT.709?

It won't when you feed RGB and request to encode as YUV- it will be always 601 (as far as I understand it).
When you encode YUV signal than it works as there is no conversion needed. I stay all the time with YUV and had no issues at all for HD sources.

Overall it could/should be improved- anything above PAL resolution should be rather converted with 709 matrix.

[Zarxrax]

I also found lagarith's null frames very useful for a few use cases that I had several years back. Basically creating graphic overlays for tv shows. The null frames were a huge help in compressing something like that, both in regards to filesize and in encoding/decoding speed.
However, utvideo's design philosophy seems very focused. Every frame is a keyframe. Adding new frametypes into the mix might be something that the developer doesn't want to do, and I certainly wouldn't fault him for that.

[qyot27]

I'd still consider it somewhat external, since it can be done without any input from the codec at all. The program (VirtualDub, ffmpeg, etc.) could be the one doing the comparison and determining whether a frame should be stored as a null or with the designated codec. Lagarith's approach internalizes the check, but there's nothing saying it has to.

[JEEB]

There is now (http://git.libav.org/?p=libav.git;a=commit;h=1ab5a780424ae8755858e153def1173a50a44e4c) Ut Video encoding support in libav, and ffmpeg has merged (http://git.videolan.org/?p=ffmpeg.git;a=commit;h=1ab5a780424ae8755858e153def1173a50a44e4c) it as well.

Multithreading isn't implemented yet, but all available prediction modes (none, left, median) are available, and all supported colorspaces are implemented. The interlaced encoding mode isn't supported at the moment.

[kolak]

Is it possible to add 10bit+ colour spaces?

[easy2Bcheesy]

Love UT Codec but am perplexed by encoding at BT.601 - why can't BT.709 be supported for acknowledged HD resolutions?

[keepert]

Preview thumbnail does not work in win8 x64. Looking in Logs is show that error was happened in dllhost.exe in module utv_core.dll. Looks like bug appeared only in x64 version. In 32 version is okay.

[Jynks]

can not read in adobe premier.. any way to get that to work.. earlier in the thread people said to install the 64 and 32 bit version.. but now there is only 1 installer for wndows.

Any ideas? On howto get prem to read the files?

[kypec]

earlier in the thread people said to install the 64 and 32 bit version.. but now there is only 1 installer for wndows.

Yes, there's only one Windows installer but it should install both versions (x86 & x64) on 64-bit OS. ;)

[foxyshadis]

can not read in adobe premier.. any way to get that to work.. earlier in the thread people said to install the 64 and 32 bit version.. but now there is only 1 installer for wndows.

Any ideas? On howto get prem to read the files?

Which version of Premiere? I might be able to help, I have CS6 at work and an old one at home, don't remember exactly which offhand.

[yup]

New version available!
For windows http://umezawa.dyndns.info/archive/utvideo/utvideo-12.1.0-win.exe
Some speed up using AVX instruction.
yup.

[kolak]

On Mac decoder always outputs (A)RGB, but UTvideo always assumes 601 color spaces, so does it mean all HD (except originally RGB) files will always look wrong?

[RTW47]

Current version 13.0.1 readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.0.1-readme.en.html) (English) / installer for Windows (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.0.1-win.exe) / zip for MacOSX (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.0.1-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.0.1-src.zip)

Others:

Fix packaging


Version 13.0.0

New features: Add codecs that use BT.709-based colorspace conversion coefficient. (FourCC: ULH2, ULH0)Others: Changed codec names.
Changed recommended CPU: Nehalem or later.

[kolak]

Great- just 10 or 16 bit mode and we are done :)

[SubOne]

Great- just 10 or 16 bit mode and we are done :)

Exactly! 10-bit would be a good start.

[kolak]

Or forget 10bit and do 16bit (probably even easier). Anything which is not 16bit fill to 16bits with 0- this will compress nicely, so won't add much of bitrate (at least in my theory:) )

[filler56789]

Version 13.1.0

Performance Improvements

ULRG,ULRA,ULY2,ULH2: Speed up encoding from native colorspace if SSSE3 instructions are available.

ULRG,ULRA,ULY2,ULH2: Speed up decoding video that were encoded with "Optimize for compression ratio" option to native colorspace if SSSE3 instructions are available.

ULY2,ULH2: Speed up encoding video from RGB formats if SSSE3 instructions are available.

ULY2,ULH2: Speed up decoding video to RGB formats if SSE4.1 instructions are available.

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

[cjplay]

This codec is great, but the HDYC support is what's getting me to use it. However, I noticed that the FFMPEG library still only shows the one 422 codec. Is there any chance of updating FFMPEG with the 709 version? Maybe "utvideo422709" for the codec or something like that?

Is there a library I can compile to use the 709 codec with FFMPEG?

Thanks for all your efforts. This codec is very welcome here.

Chris.

[cjplay]

Forgive my ignorance. I see it now in the 4CC list as ULH2 in FFMPEG. Now I just need a command to force it. My input is still a UYVY and FFMPEG is defaulting the encoder to the other 4:2:2 for UT video. Any thoughts?

Chris.

[filler56789]

Do you know of any way to force FFMPEG to output the 709, 4:2:2 colorspace version of UTVideo?

Oooops :o , I deleted my previous post, because I had misunderstood your problem :o Anyway, not really a solution, but if you're on a Windows machine, you might use Mencoder.EXE together with the UT VfW codec. Maybe you can use this combination on Linux through WINE, but I don't know whether it works or doesn't work. :confused:

[cjplay]

Thanks for the reply. I'm on Windows, so I will give it a shot. I'm especially interested in the VFW2Menc if it supports an AVI output and an STDIn.

[raffriff42]

@rean,
>hard clipping out of range
use " -pix_fmt yuv420p"

>incorrect matrix
I didn't see this, using a Fraps video as a test source
-vcodec utvideo -pix_fmt yuv420p

Opening with FFMS yielded perfect results: #avisynth
return FFmpegSource2("path to video", atrack=1).ConvertToRGB32(matrix="Rec709")
https://www.dropbox.com/s/q7izf3ewqv45u09/codec-test-2-ut420%2Bffms%2Bm709.jpg?raw=1

(EDIT viewing in Vdub with UT Video's VfW decoder +Alias Rec709 filter had a problem though - green channel clipped at around 220)
https://www.dropbox.com/s/r3heb2n70tqgunm/codec-test-2-ut420%2BVfW%2Ba709.jpg?raw=1

[raffriff42]

yuv420p will destroy chroma. I want to convert true YUV 4:4:4YUV 4:4:4 is not supported by UT Video; the choices are RGB ('ULRG'), RGBA ('ULRA'), 4:2:0/BT.601 ('ULY0') 4:2:0/BT.709 ('ULH0'), 4:2:2/BT.601 ('ULY2') and 4:2:2/BT.709 ('ULH2'). If using 4:2:0 or 4:2:2, you must choose the correct encoding matrix. (EDIT if your source is 444, you are converting to RGB, one way or the other - it's best to do so explicitly and specify the correct conversion matrix)

PS. Your images may give a sense of control, but you cannot see clipping. See the result using a histogram (YUV) or a special source (i.e. with a cloudy sky and deep blacks with details in these areas (RGB).Compare the green ridge line on the pyramid - the second one is visibly flattened. In my opinion, an image like this, with full range color ramps, is superior to Histogram for clipping detection. (EDIT it's not an image file, but a generated test pattern ('http://sourceforge.net/projects/frafstestpatt/') using DirectX9, and captured with Fraps)

I created a new RGB test video; encoded with ffmpeg (-vcodec utvideo -pix_fmt rgb24) - and the result is perfect as viewed in VirtualDub with UT's VfW decoder. No color shift, no level shift, no clipping. Also perfect as viewed in Premiere with UT's DirectShow codec.

Note I always specify my playback signal chain - you can't say, "this video looks wrong," you have to say, "this video looks wrong using decoder X and renderer Y." See for example: BT.601 and BT.709 compatibility benchmark ('http://forum.doom9.org/showthread.php?t=164378') (doom9)

[cjplay]

Bad news. A member of Zeranoe's forum updated me that the support I read about was for decoding only. Encoding is not supported yet. Bummer.

Trying Mencoder tomorrow AM.

Chris.

[raffriff42]

Source: H264 4:4:4 file with 0..255 luma

Conversion string: ffmpeg.exe -i 20121010_16425.mkv -vcodec utvideo -pix_fmt rgb24 out.avi

Resulted avi played in VirtualDub, Avisynth: FFMpegSource or Haali dss2, the same result in all cases.

Also I point you to read something about YUV->RGB conversion. It is not possible without an information about source and destination color profile knowledge.

Try -vcodec utvideo -pix_fmt yuvj444p, it works for me.

[Keiyakusha]

ffmpeg.exe -i uncompressed.avi -vcodec utvideo -pix_fmt rgb24 out.avi
(where uncompressed.avi is a YUV 4:4:4 fullrange 1080p raw video)

For me the result converted with right matrix but with clipped levels.
However as it is not possible to know what range source uses, I expect we should somehow tell ffmpeg that the source uses full range.
EDIT: h264 High 4:4:4 fullrange converted to utvideo rgb without issues!
If you have clipping, most likely fullrange flag is missing in your h264 stream. If you haven't set it during encoding, it is impossible to tell that the source is fullrange as in case of raw video.

[poisondeathray]

ffmpeg.exe -i uncompressed.avi -vcodec utvideo -pix_fmt rgb24 out.avi
(where uncompressed.avi is a YUV 4:4:4 fullrange 1080p raw video)

For me the result converted with right matrix but with clipped levels.
However as it is not possible to know what range source uses, I expect we should somehow tell ffmpeg that the source uses full range.
EDIT: h264 High 4:4:4 fullrange converted to utvideo rgb without issues!
If you have clipping, most likely fullrange flag is missing in your h264 stream. If you haven't set it during encoding, it is impossible to tell that the source is fullrange as in case of raw video.




Confirmed .

If the h.264 source file was flagged full range, ffmpeg takes that into account in the rgb conversion

-vf colormatrix=bt709:bt601 will fix the other 709/601 problem - BUT, the conversion is low quality compared to if the manipulations were done in avisynth (there is chroma aliasing and looks like it's not done at full chroma resolution maybe YUV 4:2:2) - I mentioned this ffmpeg colormatrix issue in the various other fraps threads

[poisondeathray]

ffmpeg's colormatrix was ported from avisynth - I think that's where the quality loss is occuring since colormatrix() only works with YV12/YUY2. If someone could update the avisynth colormatrix() plugin to work with yv24, I suspect it could be updated in ffmpeg .

(but it would be better if the avisynth ConvertToXX(matrix="X") functions could be implemented in ffmpeg)

[poisondeathray]

I have added option "--range pc" to x264 and reencoded the source to check. Again, in this case, I still have the same results. Anyway, this flag is not needed, because x264 automatically set it if found out of tv range values in the source stream (auto by default).

:D:D:D

In my tests, when the yv24 h.264 file encoded with x264 used "auto" it didn't work (the data was full range, but ffmpeg didn't do the RGB conversion correctly - rec601 and limited range)

But when I specified --input-range pc --range pc, it worked

x264 --crf 0 --input-csp i444 --output-csp i444 --input-range pc --range pc -o output.mp4 input.avs

[Keiyakusha]

rean
--range sets output range. To set input range you need to use --input-range. Also if they don't match - levels will be converted.
Anyway. If you think you did everything right and it still doesn't work for you, perhaps your ffmpeg revision is broken or old.

[Keiyakusha]

-vf colormatrix=bt709:bt601 will fix the other 709/601 problem
Not sure that I understand this. What problem? There is no problems not with levels, not with matrix during conversion h264 4:4:4 PC to UT RGB...

Source: h264 4:4:4 PC bt709
ffmpeg.exe -i source -vcodec utvideo -pix_fmt rgb24 out.avi
Result is right for me.

Besides why exactly utvideo? Isn't ffmpeg is the one doing conversion and then supplies uncompressed RGB to UT video? If there is a problem isn't it should be with other output formats too?

[poisondeathray]

Not sure that I understand this. What problem? There is no problems not with levels, not with matrix during conversion h264 4:4:4 PC to UT RGB...

There are 2 problems; levels (pc vs. tv) , and Rec 601 vs 709

The levels issue you addressed, but ffmpeg will always convert YUV to RGB using Rec 601 (not correct for most HD sources) instead of Rec 709

The colormatrix is a "hack"; as rean described above, you are converting in yuv 709 to yuv 601 (ie. as if the source file had been converted to YUV from a previous RGB=>YUV conversion using 601 in the first place instead of 709) - and this is done in 4:2:2, not 4:4:4. After that, ffmpeg is converting to RGB using Rec 601 (so colors match in RGB)

[Keiyakusha]

ffmpeg will always convert YUV to RGB using Rec 601 (not correct for most HD sources) instead of Rec 709

This is not true for me. Maybe I need to re-check it though but I'm pretty sure I did checked for that too.

[poisondeathray]

This is not true for me.

Well maybe something has changed in the last 2 weeks ? My binary is 2 weeks old . Are you aware of any recent changes ? I can retest it and report my observations

There are a few notable exceptions when going from RGB to YUV (normally ffmpeg uses Rec601 for everthing) , when you use v210 (10bit 4:2:2 YUV), it will use Rec709 instead of Rec601 .

[poisondeathray]

But now is a question, how to get it working directly from an avs2yuv stream...


If you're using avs /avisynth somewhere in the workflow, why not do all the manipulations in avisynth ? or am I missing something ?

[Keiyakusha]

Well maybe something has changed in the last 2 weeks ? My binary is 2 weeks old . Are you aware of any recent changes ? I can retest it and report my observations

There are a few notable exceptions when going from RGB to YUV (normally ffmpeg uses Rec601 for everthing) , when you use v210 (10bit 4:2:2 YUV), it will use Rec709 instead of Rec601 .

I don't follow ffmpeg and my build is a bit older than 2 weeks, maybe 3 or 4
1) I just made rgb fullrange 1080p reference with gradients that allow me to spot matrix conversion issues easily
2) converted it to fullrange YV24 bt709 in avisynth
3) encoded to h264 with all proper flags for matrix and levels
4) used this command: ffmpeg.exe -i source.mkv -vcodec utvideo -pix_fmt rgb24 out.avi
resulting h264 stream is confirmed to have all flags set an tested with LAV+madvr -> madvr's output matches reference video.
resulting out.avi is a perfect match to the reference minus little quality loss due to conversions

[poisondeathray]

Besides why exactly utvideo? Isn't ffmpeg is the one doing conversion and then supplies uncompressed RGB to UT video? If there is a problem isn't it should be with other output formats too?

Yes, this discussion sort of moved away from UT video strictly , the last few comments deal with ffmpeg (it's more a fffmpeg problem)




I don't follow ffmpeg and my build is a bit older than 2 weeks, maybe 3 or 4
1) I just made rgb fullrange 1080p reference with gradients that allow me to spot matrix conversion issues easily
2) converted it to fullrange YV24 in avisynth
3) encoded to h264 with all proper flags for matrix and levels
4) used this command: ffmpeg.exe -i source.mkv -vcodec utvideo -pix_fmt rgb24 out.avi
resulting h264 stream is confirmed to have all flags set an tested with LAV+madvr -> madvr's output matches reference video.
resulting out.avi is a perfect match to the reference minus little quality loss due to conversions

OK, I'll double check it .

But how did you do step 2? What matrix?

ConvertToYV24(matrix="PC.709") ?

I didn't include the --colorprim --transfer --colormatrix flags , that might be the difference...

Can you post your full command lines please ?

[Keiyakusha]

But how did you do step 2? What matrix?

ConvertToYV24(matrix="PC.709") ?

I didn't include the --colorprim --transfer --colormatrix flags , that might be the difference...

Can you post your full command lines please ?

Yes ConvertToYV24(matrix="PC.709")

--crf 0 --preset veryslow --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --input-range "PC" --range "PC"

BTW why you didn't included flags? they must be set every time regardless of what you encode for what purposes. unless you don't care about output at all...

[poisondeathray]

Yes ConvertToYV24(matrix="PC.709")

--crf 0 --preset veryslow --colorprim "bt709" --transfer "bt709" --colormatrix "bt709" --input-range "PC" --range "PC"



Thanks. Yes, out.avi is still using wrong matrix with those flags

To "view" the avs script that generated the source file, I used ConvertToRGB(matrix="PC.709") => that is what the out RGB UT Video should look like (ie. it should look like the original RGB image, minus the colorspace conversions damage)

I used a source image belle nuit test chart (One reason why it's useful, is it has 709/601 patches that can be verified in a waveform monitor, and full/std range patches)
http://www.belle-nuit.com/test-chart

ImageSource()
ConvertToYV24(matrix="PC.709")

# to view what the RGB UT video should look like
#ConvertToRGB(matrix="PC.709")



EDIT: just to clarify, I'm viewing out.avi (the RGB UT Video) in avspmod, using AVISource() , using UT Video VFW decoder. I verifed that it is indeed RGB output (not some other YUV format and some inadvertent colorspace conversion, since it's already RGB)

[Keiyakusha]

I repeated test with 1920*1080 testchart.tif (396 KB) and matrix is fine.
Note that you do see some loses especially where it shows [1] but that's not a matrix issue its a loss due to ffmpeg's conversion being low quality and in normal video you shouldn't notice it.

[poisondeathray]

I repeated test with 1920*1080 testchart.tif (396 KB) and matrix is fine.
Note that you do see some loses especially where it shows [1] but that's not a matrix issue its a loss due to ffmpeg's conversion being low quality and in normal video you shouldn't notice it.

I'm not talking about the mild losses, I'm talking about different matrix, different colors .

In fact , if I use for previewing

ImageSource()
ConvertToYV24(matrix="PC.709")
ConvertToRGB(matrix="PC.601")

It looks exactly like the UT RGB "out.avi" in terms of colors . This confirms it's the wrong matrix (601)

I'm using komisar's x264 build, and zeranoe's ffmpeg build , might that account for the difference ?

[Keiyakusha]

I'm using both private builds but I'm not aware of any patches related to this stuff...
Well, I don't know... here is my h264 file (https://dl.dropboxusercontent.com/u/110558786/Samples/matrix_test.mkv), and final UTvideo file (https://dl.dropboxusercontent.com/u/110558786/Samples/matrix_test_out.avi). You can see some differences compared to source. Mostly near [1] block, also somewhat at green color. but this is minor loses, wrong matrix will be far more visible.
I use UTvideo decoder to decode avi file, not ffmpeg or whatever.

[poisondeathray]

hmm your files look correct, correct matrix. We are getting different results

I'll check again and download new binaries, and repeat the tests, but I think it might a difference in your private build

[poisondeathray]

The difference is definitely in ffmpeg, not x264 (even using your input h.264 , I get different results)

Can you confirm ffmpeg commandline was only something like (no other ffmpeg switches ?)

ffmpeg.exe -i input.mkv -vcodec utvideo -pix_fmt rgb24 output.avi

[Keiyakusha]

The difference is definitely in ffmpeg, not x264 (even using your input h.264 , I get different results)

Can you confirm ffmpeg commandline was only something like (no other ffmpeg switches ?)

ffmpeg.exe -i input.mkv -vcodec utvideo -pix_fmt rgb24 output.avi

Yes it is. But I can confirm better. zeranoe build gives me wrong results. :devil:
ffmpeg-20130706-git-63d7684-win64-static.7z

Is there any other builds out there?

[poisondeathray]

Yes it is. But I can confirm better. zeranoe build gives me wrong results. :devil:
ffmpeg-20130706-git-63d7684-win64-static.7z

Is there any other builds out there?



Hahahaha . Ok thanks for clarifcation

Can you provide more info on the "secret sauce" that goes into your private build :)

(what patch might be the difference) ?

There is ffmbc as well , but IIRC it's the same issue (I tested these things several months ago)

[Keiyakusha]

Can you provide more info on the "secret sauce" that goes into your private build :)

(what patch might be the difference) ?

I don't know, sorry. I'm not aware of any patches at all, but you never know... It was built from ffmpeg version N-53758-g5711e4f. Maybe this is just lucky revision? ^__^

[poisondeathray]

Ok thanks. I hope it gets sorted out in zeranoe builds eventually

But we should move disucssion back to UT Video Codec (this thread), since those were ffmpeg related issues

[HulkHoganRules]

I have been using Ut video for recording from the Blackmagic cards due to HDYC color space.

I will be doing 4-5 hour recording sessions from a 720p source so lossless UT video is no longer a valid solution due to space issues.

Does anyone know of a good "lossy" codec I can use to handle the HDYC color space? It must be compatible with FFMpeg.

[HulkHoganRules]

Nevermind. Did some AVISynth wizadry and was able to losslessly capture HDYC to RGB with less bit rate than Ut. Perfect captures now. :)

[kolak]

Edited post - incorrect results before

I have just checked the resulted matrix by compare source yuv444 and result rgb one with one. Also tried to emulate matrix conversion 709->601 or 601->709 to check an idea about incorrect matrix.
The result is wrong: ffmpeg uses incorrect matrix to convert from H.264 4:4:4 to ut RGB.



It's famous ffmpeg bug and has not been fixed for ages!
It's real pain in the xxx :)

[kolak]

Nevermind. Did some AVISynth wizadry and was able to losslessly capture HDYC to RGB with less bit rate than Ut. Perfect captures now. :)

HDYC to RGB with less bitrate than Ut? It had to be really something magical :)

[acesea]

I am capturing some analog hi8 and vhs footage using ATI usb 600 svideo input into vdub and compressing with UtVideo. The work will later involve processing in avisynth, editing in premiere pro or vegas and then encoding with x264 for pc and web viewing.

There are audio sync issues depending on the lossless codec used and to get closest audio sync with UtVideo I set vdub capture timing options to sync audio to video by resampling the audio to a faster or slower rate and check correct video timing for fewer frame drops/inserts and audio latency determination automatic with 300 audio blocks to use at start.

Should I set vdub custom video format to YUY2 YUV 4:2:2 interleaved and then select video compression UtVideo YUV422 BT.601 (ULY2) VCM and check assume interlace video?

Anything else recommended for good UtVideo captures that will process and edit well without any unnecessary yuv to rgb to yuv conversions along the way? Should I keep with 601 since its SD or any reason to capture in 709 color space?

[TheSkiller]

Should I set vdub custom video format to YUY2 YUV 4:2:2 interleaved and then select video compression UtVideo YUV422 BT.601 (ULY2) VCM and check assume interlace video?
Yes.
Albeit the "assume interlace video" option in Ut Video is only for resampling color spaces which you should avoid and therefore the option is more or less irrelevant – same applies to the 601/709 variants, as long as you don't request any conversion it doesn't matter which option you choose.
For example, you feed YUY2 to the 4:2:2 601 Ut video Codec, and if you request YUY2 from the captured file later, there's no conversion.
If you need anything other than YUY2 later, you're better off using AviSynth for the conversion, in other words don't request Ut video to do any color space conversions. Ut video does it but from what I've seen it's resampling qualities are not quite ideal. It's a great lossless codec after all, it doesn't need to be good at converting color spaces, just keep that in mind. :)


Should I keep with 601 since its SD or any reason to capture in 709 color space?
Unless you choose RGB in VirtualDub and then 4:2:2 709 Ut Video, you cannot capture in anything other than 601 colorimetry anyway because there would have to be a 601->709 conversion somewhere (which there isn't), hence you always get 601. It is important to realize this: if you feed YUY2 from your capture device to Ut video you will always get 601 and choosing the 709 Ut variant over the 601 one does *not* change this.

[ChiDragon]

I am capturing some analog hi8 and vhs footage using ATI usb 600 svideo input into vdub and compressing with UtVideo.

There are audio sync issues depending on the lossless codec used and to get closest audio sync with UtVideo I set vdub capture timing options to sync audio to video by resampling the audio to a faster or slower rate and check correct video timing for fewer frame drops/inserts and audio latency determination automatic with 300 audio blocks to use at start.

Don't do that. The ATI 600 USB device captures audio internally; that option should be disabled. There is something else wrong with your setup (like capturing without a TBC, leading to frame drops).

Albeit the "assume interlace video" option in Ut Video is only for resampling color spaces which you should avoid and therefore the option is more or less irrelevant

Really? I assumed it optimized compression for interlaced sources, like the Huffyuv option.

http://wiki.multimedia.cx/index.php?title=HuffYUV#Interlaced_images

[juGGaKNot]

When i open a ut video in vegas and render it without change ( vegas preview screen says "no recompression" ) the output is bad :

http://i286.photobucket.com/albums/ll105/juGGaKNot4cs/th_bug_zps0cdb652b.png (http://s286.photobucket.com/user/juGGaKNot4cs/media/bug_zps0cdb652b.png.html)

If i edit it ( i usually crop 2 pixels on all videos ) the output is ok.

mkv > FFVideoSource avs > vdub > utvideo-13.2.1-win ( "predict left" ) > sony vegas > utvideo

77 videos, any unedited one output = same as the picture up there.
If i apply a crop = all videos ok

Problem at my end ?

[Atak_Snajpera]

what is resolution reported in vdub? most likely it is not mod4.

[juGGaKNot]

what is resolution reported in vdub? most likely it is not mod4.

Codec ID : ULRG
Codec ID/Info : Ut Video Lossless Codec
Codec ID/Hint : Ut Video
Duration : 35s 744ms
Bit rate : 118 Mbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps

Original and output are the same resolution, 720p

Looks ok in vdub, if i open it in vegas and render as ut again looks bugged. If i crop in vegas before rendering it looks ok. I crop all the sides ( aspect ratio locked ) not just vertical crop ( and this is just for that 1 pixel border ).

[Lenchik]

Does anyone have contact of developer of these codecs? Can we ask him to add support for YV24, please? Maybe he is planning it already?

[zerowalker]

You can try ask in his blogg.
Sadly i don´t think you know automatically if he answers.
But i believe his has answered me when i checked, though it took awhile, and i think he answered in Japanese.
At least i think he did answer;S

[Keiyakusha]

There's no need for YV24 when there is RGB(A)
Any source you produce yourself is RGB(A) so keep it this way. Every source you get from bluray, dvd and such is 4:2:0 or 4:2:2.

[Lenchik]

Even if the source is MJPEG screencapture with 4:4:4 color preservation? AFAIK YUV > RGB > YUV is not lossless.
However i don't know if there is difference for UTVideo RGB(a) in YV24 and RGB source.

[nevcairiel]

Your screen is already RGB, so you should keep it RGB and encode it like that. :)

[poisondeathray]

Yes for screen captures you should use RGB

But if you still need a lossless YV24 codec for your previous capture, ffmpeg's implementation of FFV1 supports YV24 now . But it's seek/decoding performance is sluggish compared to UT Video

[Keiyakusha]

Even if the source is MJPEG screencapture with 4:4:4 color preservation? AFAIK YUV > RGB > YUV is not lossless.
However i don't know if there is difference for UTVideo RGB(a) in YV24 and RGB source.

I really don't see why would you want to convert mjpeg into UTvideo. If your goal is to use utvideo as an intermediate format for editing (which is one of its main goals) then mjpeg isn't any worse and you can just keep it as is. It should be super fast too! Otherwise converting it to UTvideo will only result in increased filesize and nothing else.
Of course going YUV4:4:4>RGB will result in some loses. But seeing how you used mjpeg to begin with, loses from this conversion will be so small, you can assume there is none. So if you still need utvideo fir some reason, you can still go with RGB.

[Atlantis]

I have a ut video created by myself. Wanted to encode it to h264 using MeGUI. How do you do it?

I used file indexer and ffms2. When I encode the created avs file, the resulting h264 file plays back jerky. I think ffms2 doesn't index correctly utvideo.

If I open the avi file directly with AVISource(), the encoded h264 file plays correctly. Any ideas? FFMSIndex has problems with utvideo?

[WorBry]

Looks like you have done it !

Probably others could explain the jerkiness, but why would you want to use ffms2 anyway, since you clearly have the vfw UT-Video codec suite installed and you don't have any problems with the AVISource to x264 transcode. Can't imagine it's a question of speed as the vfw UT-Video decompressor is darn fast (Left prediction especially). And if you've generated the avs script with the MeGUI AVS Script Creator tool why even bother with the extra (ffms2) indexing step if it loads directly as an AVISource?

[Atlantis]

Because I tried to learn from MeGUI. When you add a pre-rendering job and MeGUI creates a lossless Huffyuv, it opens it with ffms2.

Please explain to me why MeGUI opens its lossless Huffyuv created by itself with ffms2?

[the_weirdo]

Please explain to me why MeGUI opens its lossless Huffyuv created by itself with ffms2?

Because it doesn't know if you have Huffyuv VfW decoder installed or not, so it uses FFMS2 which doesn't depend on that factor.

[WorBry]

..... Can't imagine it's a question of speed as the vfw UT-Video decompressor is darn fast (Left prediction especially)

Qualification on that. The UT-Video vfw decompressor is intrinsically very fast; in my tests, UT-Video YV12 (Left Pred) decompresses around 6 x faster than Huffyuv YV12 (vfw FFDShow) in 32-bit mode and faster still (7 x) in 64-bit. But of course, 'in-use', other influential factors (limiting and accelerating) come into play.

Here's a quick comparison of AVS output rates (AVISource vs ffms2) using AVSMeter(v174 AVS2.6_x86)

Test AVISource: Uncompressed YV12 clip (1440 x 1080, 25p, 2000 frames) encoded to UT-Video (v 13.3.1) YUV420 BT.709 with Left Prediction (Frame Divide Count 6). Compression ratio: 2.02

AVS scripts prepared with MeGUI AVS Script Creator; MeGUI v2418, AVISynth 2.6 MT (SEt’s, in non-MT mode...so as not to complicate matters). No other filters in script.

PC: Hex-core CPU (AMD-FX-6300), 8GB RAM, Win7 64-bit

AVSMeter Results:

AVISource.avs :
Average fps: 107.42
Av cpu use: 28%
Threads 7
Physical memory peak: 13MB

ffms2.avs: (FFVideoSource int threads: 1 - as set by AVS Script Creator)
Average fps: 45.32
Av cpu use: 16%
Threads 6
Physical memory peak: 14MB

BUT..........

ffms2.avs: (FFVideoSource int threads: -1 (default) = # logical cores)
Average fps: 208.03
Av cpu use: 89%
Threads 11
Physical memory peak: 35MB

And just for comparison:

Test AVISource: same raw source encoded to Huffyuv (vfw FFDS*) YV12, Left Prediction (Huff tables) *FFDShow Tryouts rev4525
Compression ratio: 2.02 (same as UT-Video)

AVISource.avs: (vfw FFDShow decoder: # decoding threads: 6)
Average fps: 60.70
Av cpu use: 16%
Threads: 2
Phys memory peak: 20MB

ffms2.avs (FFVideoSource int threads: 1 - as set by AVS Script Creator)
Average fps: 50.75
Av cpu use: 16%
Threads: 6
Phys memory peak: 15MB

ffms2.avs (FFVideoSource int threads: -1 (default) = # logical cores)
Average fps: 206.62
Av cpu use: 82%
Threads: 11
Phys memory peak: 42MB

Clearly enabling full (default -1) internal MT support in FFVideoSource makes a huge difference for both UT-Video and Huffyuv. I see there is an option in the MeGUI Settings to set the FFMS thread count, and that it defaults to 1. I wonder why not -1 ? I can only assume that it is to give MT CPU priority to the encoder? Something to be aware of, as I often use the tool just to start an AVS script for purposes other than MeGUI mediated encoding.

[WorBry]

.... I see there is an option in the MeGUI Settings to set the FFMS thread count, and that it defaults to 1. I wonder why not -1 ? I can only assume that it is to give MT CPU priority to the encoder?

Doesn’t appear to affect the x264 encode rate much though:

Input: Same AVS scripts as above for UT-Video YV12 (Left)
x264 encode settings:
program --level 4.1 --preset slow --tune film --crf 18.0 --vbv-bufsize 78125 --vbv-maxrate 62500
--colorprim bt709 --transfer bt709 --colormatrix bt709 --output "output" "input"Output: RAWAVC
‘Normal’ priority

x264 encode rates (fps):
AVISource.avs : 11.25
ffms2.avs (int threads 1) : 11.06
ffms2.avs (int threads -1) : 11.15

Not much difference there, but possibly I/0 read/write rates are limiting anyway; I'm running with a single internal SATA-3 HDD atm.

All three x264 encodes (muxed to mp4) play back perfectly well (MPC-HC, VLC) BTW, so regarding:

I have a ut video created by myself. Wanted to encode it to h264 using MeGUI. How do you do it?
I used file indexer and ffms2. When I encode the created avs file, the resulting h264 file plays back jerky. I think ffms2 doesn't index correctly utvideo.
If I open the avi file directly with AVISource(), the encoded h264 file plays correctly. Any ideas? FFMSIndex has problems with utvideo?

......I don't know the reason why you got jerky playback with your ffms2 x264 encode.

[WorBry]

Because I tried to learn from MeGUI. When you add a pre-rendering job and MeGUI creates a lossless Huffyuv, it opens it with ffms2.

Please explain to me why MeGUI opens its lossless Huffyuv created by itself with ffms2?

Ah, realize now, likely reason is because you already have an ffindex file in the same folder as your Huffyuv file and with the same file name. So when you open the Huffyuv with AVS Script Creator, it picks up the ffindex file instead and loads the Huffyuv via ffms2. Delete the ffindex file and you'll find that you are again given the option to load the Huffyuv as an AVISource, assuming of course that you have have the appropriate vfw Huffyuv decompressor installed (or enabled, if using vfw FFDShow).

[Atlantis]

Yes but when I index my Ut Video with ffms2 I also have a ffindex file for my ut video and its still choppy when I encode.

[WorBry]

That's a separate issue and...


......I don't know the reason why you got jerky playback with your ffms2 x264 encode.

Well, if someone more knowledgeable than I doesn't pick up your query on this thread, I can only suggest addressing the issue on the FFMPEGSource thread:

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

or equally gigantic 'MeGUI: General Questions and Troubleshooting Thread'

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

But not both ;)

Only other thing I can suggest is testing your ffms2 avs script to encode to something else (HuffYuv or whatever in VDub) and see if you still get a jerky video, that might point to the indexing. And does your Huffyuv.avi (or another format.avi file) loaded with ffms2 also produce a 'jerky' x264 encode or is it just the UT-Video avi ? Such is my 'process of elimination' approach to troubleshooting. Like I said, others more knowledgeable would likely be able to better pinpoint the cause.

[WorBry]

I see FFMPEG also supports UT-Video encoding.

I’m very new to FFMPEG and have only run a few simple transcode commands. Taking this basic script for converting a RawYV12 avi clip (typically 1440x1080, 25p) to UT-Video:

ffmpeg -i C:\RawYV12FFDS.avi -vcodec utvideo -an UTVYV12.avi

Could someone please advise how I should amend the script to match the configuration options in the vfw version:

Left or Median prediction - I assume default would be Left, but how to set Median?

Interlaced - my sources are typically progressive, but how to set interlace support if required?

Multi-threading support - if indeed this is supported in the FFMPEG UT-Video implementation?

Also, assuming this is an implementation of the BT.709 version - how to specify YUV422 (ULH2) and YUV420 (ULH0) or is that just set by the pixel format -pix_fmts?

I’m using Zeranoe ffmpeg win64-static build (20140125-git-5554c6d).
PC has hex-core CPU (AMD FX-6300) running Win7 64-bit

Thanks a lot.

[WorBry]

Does the UT-Video developer (or his representative) not visit these pages anymore?

[raffriff42]

These are more ffmpeg questions than utvideo, but looking at the source code (https://ffmpeg.org/doxygen/trunk/utvideo_8h_source.html) and doing some experimentation, I can say: it appears left, gradient and median prediction are supported (-pred left|plane|median)
RGB, RGBA, 422 and 420 supported
-pix_fmt rgb24 => "ULRG"
-pix_fmt rgba => "ULRA"
-pix_fmt yuv420p => "ULY0" (4:2:0 BT.601)
-pix_fmt yuv422p => "ULY2" (4:2:2 BT.601)
the code contains an interlaced flag; don't know if it's functional
don't know about multithreading (but doubt it is supported)

[JEEB]

With regards to the libavcodec Ut Video encoder's capabilities I recommend taking a look at the initialization function utvideo_encode_init in utvideoenc.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/utvideoenc.c).

Left and median prediction are indeed implemented. I think gradient prediction was really nowhere to be seen so it is not implemented, the encoder will throw up an error if you try to use it :) . There is also a prediction mode 'none', which is generally useless, but I guess it can be useful with pictures that contain absolutely nothing but a single value.

The specific interlaced coding mode is not supported as my mentor did not see much worth in it. Such content will get encoded the same way as progressive content will be currently (at least I do not either remember or see any errors being thrown at interlaced content as such.

Currently the libavcodec encoder is not threaded. Everyone wanted to have slice-based threading for the Ut Video encoder, which would have needed some new things to be added related to how the huffman coding is done, among other things. I have a patch from Daemon404 for the non-huffman parts of slice-based threading, but he said it was not really faster at all because of the huffman coder being at the end of it.

On the other hand, picture-based threading would be probably pretty simple to implement, and I think at this point it would probably be the better way to get at least some kind of threading to the encoder. Not to mention that while picture-based threading generally uses more memory (multiple pictures in memory being encoded at the same time), it is generally the threading model that ends up being faster.

The implementation was coded before the new FourCCs were added to Ut Video. And it seems like while the libavcodec decoder got patched by someone for the new FourCCs (see decode_init in utvideodec.c (https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/utvideodec.c)), the encoder did not (I am not sure of the whole hardcoding of things to AVCOL_SPC_BT470BG in case of the old YCbCr FourCCs in the decoder). This should probably be the simplest addition.

Additionally I guess there should be a setting to set the amount of slices used by the encoder. It is currently hardcoded to one, as that gives the best compression ratio (the actual encoder internals can handle more slices just fine). That said, the official Ut Video decoder is slice threaded, so it probably has a bit of a negative effect on that.

Edit: Posted a patch (http://patches.libav.org/patch/46933/) for the BT.709 FourCC on libav-devel, That way the feature will go into both FFmpeg and Libav, as FFmpeg merges libav commits almost daily.

[WorBry]

Thanks both. I'm afraid I have no understanding of source codes, but thanks for the advice and update.

So, just to be clear, with the BT.709 FourCC update, it will be:

-pix_fmt yuv420p => "ULH0" (4:2:0 BT.709)
-pix_fmt yuv422p => "ULH2" (4:2:2 BT.709)

Actually, I'm mostly using the vfw UT-Video codec which I've found to be easily fast enough for use as a lossless edit format in the NLE I use at present (Corel VideoStudio Pro x6). Although VSPro, as yet, only supports 32-bit vfw codecs, it has good MT support.

This in turn got me wondering whether the FFMPEG implementation of UT-Video might have similar application in a Linux - possibly as an alternative to 'Matroska Lossless' (Huffyuv/Flac) in KDenLive.

10-bit 4:2:2 support (in both vfw and FFMPEG implementations) would, of course, be the icing on the cake. Any movement on that? I know Windows has Cineform and Linux has DNxHD, but a fast lossless 10bit codec would be priceless.

[JEEB]

To be exact, it is like this:

if decoder has set colorimetry to BT.709 and the format is YCbCr?
-> Use the BT.709 FourCC
in other cases with YCbCr
-> Use the older FourCC

(or actually, encoder's context is what is read, but in ffmpeg and avconv the system sets the encoder's context's values according to the decoder's)

Now, the only problem that I notice is that initialization of the encoder is done quite early in the process (this is where the FourCC is set), and the decoder has not yet decoded anything. Thus in many cases the source's colorimetry is not yet set at that point, and even if the source is marked as BT.709 it might not get encoded as such. I will later see if FourCC settling could be moved to the actual encoding side of things. Rather unfortunate that Ut Video ended up taking the route of multiple FourCCs instead of bitstream/extradata flags. This can be of course overridden with -colorspace 1 (1 being the number of BT.709) on the encoder's side of settings (after -i).

As for high bit depth lossless coding, you might want to try ffvhuff or ffv1, I think both of them currently have >8bit lossless coding in FFmpeg.

Edit: Or heck, even libx264 with quantizer set to zero with a fast preset.

[WorBry]

Thanks again. So if I understand correctly, your advice is to force BT.709 colorimetry (using -colorspace 1), for the time being, to avoid any possibility of the encoder not picking up the source colorimetry flags? And for FFMPEG decoding of (FFMPEG-encoded) UT-Video - any issues or precautions to be taken there, or are the colorimetry flags set as they should be ?

As for high bit depth lossless coding, you might want to try ffvhuff or ffv1, I think both of them currently have >8bit lossless coding in FFmpeg......
Edit: Or heck, even libx264 with quantizer set to zero with a fast preset.

But, AFAIK, there are no 10-bit lossless vfw codecs out there, at least that are accessible as such. Canopus Lossless is 10-bit in Edius, but (as I recall reading) when accessed as a free-standing vfw codec (through the free Canopus codecs pack) it is only 8-bit ......and much slower. When I compared vfw codec decompression rates (32-bit and 64-bit) Canopus Lossless was essentially on par with ffhuff-YUY2-Left pred (FFDShow). UT-Video (left) decompressed 7 x faster in 32-bit mode and even faster (7.5 x) in 64-bit - twice that even of Cineform (Film Scan 1), which is judged to be pretty fast. Cineform (Film Scan 2) comes darn close to lossless (with SSIM scores consistently exceeding 98% in my tests; Canopus HQX Superfine also) - but it's a monster to edit and at the bitrates/file sizes generated one might as well be using a true lossless - and neither ffhuff nor FFV1 (vfw FFdshow) cut it - at least on my system (hence the possible interest of editing with FFMPEG in Linux).

Granted, one might question the benefit of a 10-bit lossless intermediate when editing 8-bit sources with (consumer level) 8-bit editing software. But having looked at a variety of 8-bit footage, I've observed a noticeable reduction in posterization artifacts (inherent in the source or otherwise generated) when using Cineform (Film Scan 1) as an edit intermediate....at least in Corel Video Studio Pro x6 which (despite the 'Pro' epiphet) still only edits in 24bit RGB colorspace. Part of that could well derive from the wavelet compression, but I'm seeing some improvements (albeit slight) also when comparing 10-bit and 8-bit (FFMPEG) DNxHD encodes.

So, it's not only the Professionals who would welcome a 10-bit incarnation of UT-Video.

If the reason is lack of adequate resources to develop and test 10-bit, surely someone could help out? Just seems a pity that having come all this way, with such phenomenal improvements in performance, that this presents such a hurdle. :(

[WorBry]

...... Canopus Lossless is 10-bit in Edius,
Correction: Only Canopus HQX is 10-bit in Edius. Canopus Lossless is 8-bit in and outside Edius:

http://forum.grassvalley.com/forum/showthread.php?t=24932

Also just came across this:

http://forums.adobe.com/thread/1252087

What's that all about - UT-Video maybe not really lossless?? :scared: I wonder if the guys original footage was 10-bit; might explain the banding on the 8-bit UT-Video gradient ? If so, yet another reason why UT-Video needs 10-bit support ;)

[raffriff42]

UT-Video maybe not really lossless?? :scared: 2nd image has been resized; the comparison is invalid for this and other reasons.

However...

Comparing Fraps source (YUV full-range 709) encoded with ffmpeg/utvideo, the result is clamped to 16-235.
(EDIT - I should say, the result is clamped in the U & V channels only!)
https://dl.dropboxusercontent.com/u/108089426/Screenshots/utvideo-compare-yuv-02a.jpg
https://dl.dropboxusercontent.com/u/108089426/Screenshots/utvideo-compare-yuv-02b.jpg

This applies to the ffmpeg version only, and only the YUV flavor. ffmpeg/utvideo in RGB mode is fine. The VfW version is fine.

Repeat, the result is clamped in the U & V channels only. In ffmpeg's defense here, full range YUV is not really legal in the first place! (but it's common in captured sources)

(also, ULH0 / BT.709 does not seem to be supported in ffmpeg, but this is not important IMHO.)

[JEEB]

Comparing Fraps source (YUV full-range 709) encoded with ffmpeg/utvideo, the result is clamped to 16-235.

This applies to the ffmpeg version only, and only the YUV flavor. ffmpeg/utvideo in RGB mode is fine. The VfW version is fine.

Repeat, the result is clamped in the U & V channels only. In ffmpeg's defense here, full range YUV is not really legal in the first place! (but it's common in captured sources)

This is not related at all to the Ut Video encoder itself, but to how ffmpeg works. There is no clamping in the encoder. Try to specify the range on either/both side(s). Also make sure that the data is actually clamped and not clamped by the YCbCr→RGB conversion that comes after that (full range YCbCr read as limited range because it has no full range flag).

But yes, Ut Video has no flag for limited/full range, so I really can't recommend using it for full range content. But the encoder itself should not and does not clamp anything. It just encodes whatever you pass to it as-is.

Edit: Because of how the swscale system works, the conversion from full range to limited range can't be skipped in command line ffmpeg. Welcome to swscale, although after some thought it's a damn brainfart to use a thing that can't signal stuff for full range content. Save this kind of stuff for formats that actually can convey the information down the goddamn chain. It only "works" in VfW because the framework is as dumb as a brick. That said, if the conversion is done incorrectly (I have not checked for it, just for the fact that the information actually changes), feel free to poke the related project to fix it.

(also, ULH0 / BT.709 does not seem to be supported in ffmpeg, but this is not important IMHO.)
The decoder has supported it for quite some time now as far as I can see (albeit I do not fully agree with how it works right now, where the old YCbCr FourCCs are interpreted as AVCOL_SPC_BT470BG -- after all, those FourCC have been used for all Ut Video YCbCr content before; it should instead not lead to anything, to be undefined).

The encoder has had support for the BT.709 FourCCs for four hours now in libav, and FFmpeg has just merged it. Now both libav and FFmpeg support it.

Do note, though, that the libutvideo encoder does not seem to use the BT.709 FourCC (decoder seems to have an ifdef and uses it), I am only speaking of the internal libavcodec implementation, which I coded during the summer of 2012.

[raffriff42]

Thanks, JEEB. I should mention, before someone else does, about the apparent residual color matrix error and slight chroma smearing: these are both due to the Fraps decoder's YUV to RGB conversion. The UTvideo screenshot is actually more correct in these areas. (Should've used FFmpeg input plugin for my tests)

[WorBry]

Well, like I said, part of my interest was in the potential use of Ut-Video as lossless edit intermediate in Linux, primarily KDenLive which, as far as I can tell, edits in RGB color-space (that assumption being based on there being no mention of an option to set the edit color space otherwise). In which case, proper recognition and respect of color-matrix flags would be important. That said, there appears, at this time, to be no option to configure a custom transcode format in KdenLive - (thinks ) I wonder though if modifying the script of one of the 'canned' transcode formats (Matroska Lossless maybe?) could be made to work with UT-Video - not at my home pc just now, but might try that. But that would, in turn, need the UT-Video Rec.709 update to be in the Ubuntu libav libraries that KDenLive uses. Not sure know how that works - would they be updated daily also?

This is not related at all to the Ut Video encoder itself, but to how ffmpeg works......
But yes, Ut Video has no flag for limited/full range, so I really can't recommend using it for full range content. But the encoder itself should not and does not clamp anything. It just encodes whatever you pass to it as-is.


Hmmm....didn't realize that. So does that mean that full-range content is going to get clamped in KDenLive with any of the transcode formats? Not sure I'd want that.

[JEEB]

Well, like I said, part of my interest was in the potential use of Ut-Video as lossless edit intermediate in Linux, primarily KDenLive which, as far as I can tell, edits in RGB color-space (that assumption being based on there being no mention of an option to set the edit color space otherwise). In which case, proper recognition and respect of color-matrix flags would be important.
Now, first of all, with video editors you have some stuff that you have to make sure before hand, if you even want to have them handle YCbCr content. And yes, in most cases editing itself is done in RGB space. Pictures are decoded and converted, and then filtered, and then thrown towards an encoder again, possibly converted back to YCbCr if the encoder is not set to RGB.

Your first problem is to check if the editor handles colorimetry at all. Encode some shade of, say, light blue, and stick different colorimetry metadata to it. Use a format that doesn't do hackjobs for this information, such as H.264. See if it makes any difference at all.

After that, if you really wanted to have full control on things, I'd still recommend a format that can signal this stuff properly.

But that would, in turn, need the UT-Video Rec.709 update to be in the Ubuntu libav libraries that KDenLive uses. Not sure know how that works - would they be updated daily also?
No, official repositories of distributions that actually have releases always stay on the major version that was in when the release was made (and usually a few months before that). Also with things like FFmpeg or Libav there is also a rather large amount of work to be done to update everything that depends on their libraries so that it all works with the new version. And the amount of things depending on these libraries is rather large.

Every current stable Ubuntu release to this date has Libav 0.8, released 21st of January, 2012. It has the decoder, no encoder. No idea how many Ut Video decoder fixes have since been backported into the 0.8 branch. 14.04 will either have Libav 9 or Libav 10, depending on if the Debian/Ubuntu maintainer will be able to update things.

Hmmm....didn't realize that. So does that mean that full-range content is going to get clamped in KDenLive with any of the transcode formats? Not sure I'd want that.
What was just talked about was looking at the content as if it was full range YCbCr. RGB is not related in any way or form (or actually it is, but pretty much no-one uses limited range RGB in such use cases).

ffmpeg (the command line app) saw that what the decoder would output was not what the encoder would take in (for swscale the full range and limited range 4:2:0 are separate "pixel formats"), and a conversion happened. In all theory this is correct. Your output format is not capable of distinguishing between limited or full range YCbCr, and thus your content is converted to limited range, so that it can be correctly handled by other things. Whether or not this conversion was done correctly is out of the scope of this post, and if it is incorrect then I strongly recommend reporting it at the given upstream project :P .

If the system in the command line ffmpeg was somewhat better, you could have forced it to not convert. That said, you really don't want it. You would lose all metadata about the range. It only "works" in VFW because VFW is dumb and has absolutely no idea about these things. It just passes one filter's output to another filter's input as long as the general pixel format is the same. After that passing has happened, no-one and nothing else but you can do anything to that content correctly. Manually, of course.

As for editors and full/limited range YCbCr? No idea. Up to the editor. If your input format is something that can actually signal the YCbCr range, it might get read in properly and converted correctly to RGB for editing. Of course, this depends on how intelligent the input module is as well. If your editor's input module has no idea of these things or how to push them further down the chain, you are just screwed. Like with VFW, for example (stuff like FRAPS can have its own special decoder that can output straight into RGB and do the conversion itself; a Ut Video decoder would not be able to do this because it has absolutely no way of knowing what range you have in there, so it would have to just handle it as limited range YCbCr or full range RGB).

As for export, no idea either. I would guess that unless you hack around hard your things would get converted to limited range YCbCr in case of YCbCr. And full range RGB in case of RGB.

Long story short, if I had to use something that I have no idea of how it does things, I would just convert to RGB in the exact way I would want to before editing, and then export in RGB, and then convert that into YCbCr again in the exact way I wanted.

[JEEB]

Additionally I guess there should be a setting to set the amount of slices used by the encoder. It is currently hardcoded to one, as that gives the best compression ratio (the actual encoder internals can handle more slices just fine). That said, the official Ut Video decoder is slice threaded, so it probably has a bit of a negative effect on that.
An update on this, I have posted a patch (http://patches.libav.org/patch/47263/) to make the lavc Ut Video encoder use multiple slices. If nothing is specified, slice count is set to <subsampled height> / 120 . So everything up until 239 samples of height will have one slice, and 240+ will have two, and so forth. This is calculated from the chroma subsampled height in case of 4:2:0 YCbCr for example, so less slices are used then :) (but you do get at least two with 4:2:0 480p).

Naturally, you can override this by using the -slices parameter as well :) .

[qyot27]

Do note, though, that the libutvideo encoder does not seem to use the BT.709 FourCC (decoder seems to have an ifdef and uses it)
It was mainly because I wasn't sure how to handle the decision in the encoder's switch case. The fix for the native encoder can be safely re-applied against libutvideoenc with little modification, though.

Although the discussion above concerning featureset led to more testing that uncovered the fact that libutvideoenc seems to be locked to median prediction. I'm also not sure if multithreading is used when libutvideo is selected, nor how much of an impact enabling the assembly really has (except that enabling both it and building as a shared library results in broken builds).

Really, the use case for libutvideo over the native implementation is as a reference.



(to be honest, I just use ffvhuff - the higher bit depths and extra colorspaces need -strict experimental, so using those seamlessly has to wait until it gets finalized; there's always FFV1 for those scenarios in the meanwhile)

[JEEB]

An update on this, I have posted a patch (http://patches.libav.org/patch/47263/) to make the lavc Ut Video encoder use multiple slices...
This feature is now in both Libav and FFmpeg. Now what's left is threading. Will have to look up a similar intra-only and frame/picture-basely threaded encoder as an example.

The fix for the native encoder can be safely re-applied against libutvideoenc with little modification, though.
Might poke Daemon404 for this at some point. After all, he is the maintainer for the libutvideo wrappers :) .

Although the discussion above concerning featureset led to more testing that uncovered the fact that libutvideoenc seems to be locked to median prediction. I'm also not sure if multithreading is used when libutvideo is selected, nor how much of an impact enabling the assembly really has (except that enabling both it and building as a shared library results in broken builds).
At least median is generally what people most probably want to have. Multithreading-wise in theory it should have it, and the asm probably has some effect on the result? Also lol at the broken build. Will poke youm on #utvideo@freenode later I guess.

(to be honest, I just use ffvhuff - the higher bit depths and extra colorspaces need -strict experimental, so using those seamlessly has to wait until it gets finalized; there's always FFV1 for those scenarios in the meanwhile)
Yeah, ffvhuff is a nice one. Had used it for a long time before Ut Video came around, and still use it at times. The main reason to use Ut Video is for intercompatibility, really. It has a decoder component in pretty much every major multimedia framework by now, in addition to the support in libavcodec (VFW, DShow, QuickTime, MF...).

[qyot27]

Might poke Daemon404 for this at some point. After all, he is the maintainer for the libutvideo wrappers :) .
I can just send a patch with all the original commit info intact. Maybe add a blurb in the commit message that it's been slightly modified for the lib wrapper.

At least median is generally what people most probably want to have. Multithreading-wise in theory it should have it, and the asm probably has some effect on the result? Also lol at the broken build. Will poke youm on #utvideo@freenode later I guess.
With the asm, what I meant is that when I tried enabling it, it didn't seem to speed anything up, and this was on a system that would have at least the SSE2 support available (CPU was an Athlon64 Orleans). Maybe the Orleans' SSE2 support just sucks - it wouldn't surprise me.

The situation with libutvideo is a bit...sticky. The ability to build libutvideo from the official source zip was removed a few versions back. The only reason newer versions of it can still be built is because I kept the GNUmakefile and the more fleshed-out buildsystem patches alive on Github (http://github.com/qyot27/libutvideo).

[RTW47]

Version 14.0.0
New features
•Add a codec whose internal format is YUV422 10bit. (FourCC: UQY2). Very slow.
Others
•Changed codec names.
•Changed minimum requirement OS: Windows Vista or later.
readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-win.exe) / Mac OS X (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.0.0-src.zip)

[kolak]

10 bit support ☺
Great news.

[Sparktank]

Just saw that there was an update on VideoHelp.com

Version 14.1.1

New features
UQY2: Restriction of video width is relaxed.


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

Official Site (sorted by Last Modified descending):
http://umezawa.dyndns.info/archive/utvideo/?C=M;O=D

[Selur]

Where do I find some documentation about the arguments accepted by ffmpeg for utvideo? (as a aside note: also looking for the same info in regard to ffvhuff)

[raffriff42]

Where do I find some documentation about the arguments accepted by ffmpeg for utvideo?Looking at the source code (http://www.ffmpeg.org/doxygen/2.0/utvideoenc_8c_source.html#l00057), to me it appears that there are only two user variables from AVCodecContext used in the encoding process:

Pixel format (-pix_fmt) options are rgb24, rgba, yuv420p and yuv422p.
(Note ffmpeg sets the default pixel format for you, based on your source format, so this argument is not needed unless you want to force a format conversion)
(BTW, for YUV, the Rec.601 (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.1.0-readme.en.html) variants are used: yuv420p fourcc = ULY0, yuv422p fourcc = ULY2)

Prediction method options appear (http://www.ffmpeg.org/doxygen/2.0/utvideoenc_8c_source.html#l00120) to be left (-pred left, the default) or median (-pred median)
(left is supposed to be faster, median is supposed to give better compression)

EDIT okay, there's more than two; there is one more item of possible interest: Slices (for example, -slices 4)
There was no effect on encoding speed in my very short test video, but the binary output was slightly (0.02%) larger, so something happened. Needs more looking-into.

[Selur]

Thanks a lot raffriff42!! :)

[qyot27]

(BTW, for YUV, the Rec.601 (http://umezawa.dyndns.info/archive/utvideo/utvideo-13.1.0-readme.en.html) variants are used: yuv420p fourcc = ULY0, yuv422p fourcc = ULY2)
This can be changed with the -colorspace option.
ffmpeg -i input -vcodec utvideo -pix_fmt pixfmt -colorspace bt709 output.avi
automatically selects the ULH* variant of the pixfmt.


At the current time, neither the native utvideo codec nor libutvideo wrapper exposes the 10-bit form introduced in version 14. I tried to fiddle with it a while ago to see if I could do it, but it wasn't allocating the right side of the image.




And just because I mentioned it earlier, ffvhuff no longer requires -strict experimental to use the huge array of additional pix_fmts.

[raffriff42]

This can be changed with the -colorspace option.Thank you, that's good to know!

[BlockABoots]

Am about to try out the utvideo codec for the first time, but noticed there are 7 decoding options...

(ULH0)
(ULH2)
(ULRA)
(ULRG)
(ULY0)
(ULY2)
(UQY2)

Can some one explain what each one is please. If im wanting to used the codec to record xbox one game play and then retro stuff (NES, SNES) which ones should i be picking?

[raffriff42]

I assume you mean 'encoding options' ?

If your source is 720p or 1080p, start with 'ULH0' (YUV 420 BT.709), but I would test 'ULY0' (YUV 420 BT.601) as well, choosing whichever looks 'better' (least saturation shift in greens & reds) in your chosen editor program.

If you have fine color detail (thin lines, small fonts) and you want to upscale from (for example) 480p to 720p, you may want 'ULRG' (RGB). You will probably have to convert to YUV 420 for the final product anyway, but doing so after upscaling looks a bit better. The downside of RGB is larger file size.

For really retro stuff (360p or below) I would definitely capture in RGB mode and scale up to HD for the final video.

There are threads on doom9 about upscaling pixel games...EDIT here's the one I was thinking of:
http://forum.doom9.org/showthread.php?t=170661

[rikai]

Figured i'd point out the 14.2.0 release here from back in june since nobody else had. :)

Version 14.2.0

Performance Improvements
•UQY2: Add support for multithreading.

readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-win.exe) / Mac OS X (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-macosx.zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-14.2.0-src.zip)

[nhope]

Anyone having any luck rendering 10-bit? I'm choosing the "UtVideo Pro YUV422 10bit VCM" option and have tried a few resolutions and frame rates but rendering in Vegas Pro it always tells me "The selected codec does not support the current render settings." In VirtualDub it says "Couldn't find compatible format. Possible reasons: *Codec may only support YUV *Codec might be locked *Codec might be decompression-only".

[Ignus2]

Anyone having any luck rendering 10-bit? I'm choosing the "UtVideo Pro YUV422 10bit VCM" option and have tried a few resolutions and frame rates but rendering in Vegas Pro it always tells me "The selected codec does not support the current render settings." In VirtualDub it says "Couldn't find compatible format. Possible reasons: *Codec may only support YUV *Codec might be locked *Codec might be decompression-only".

As the reply would lead to very off-topic discussion, I answered here:
http://forum.doom9.org/showthread.php?p=1702245

Greets,
I.

[RTW47]

readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-readme.en.html) (EN) / Windows (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-win.exe) (exe) / Mac OS X (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-macosx.zip) (zip) / source (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.0-src.zip) (zip)

New features:
• Add QuickTime components (both encode/decode) for Windows.
• ULY2, ULH2, ULY0, ULH0: Add support of YUV422 input/output on QuickTime components.
• UQY2: Add QuickTime components.

[kolak]

Interesting!:thanks:

[cez4r]

Version 15.0.1 (http://umezawa.dyndns.info/archive/utvideo/)

"For some reasons, rebuilt and re-packaged." — 15.0.1 readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.1-readme.en.html)

[kolak]

Qt 10bit was badly crashing QT player for me.

Next step is 16bit with RGB support.

[kolak]

Version 15.0.1 (http://umezawa.dyndns.info/archive/utvideo/)

"For some reasons, rebuilt and re-packaged." — 15.0.1 readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-15.0.1-readme.en.html)

Installer was infected.

[cez4r]

Thanks.

And the author totally removed 15.0 versions for Windows from his site...

[LigH]

Infection seems to be not so certain, only suspicious as generic backdoor, but by almost half the engines used by VirusTotal.

VirusTotal reports: utvideo-15.0.0-win.exe (https://www.virustotal.com/de/file/9fceb488fcb4d5a50a961d7d58bc7140b80985d5a52e1cdc1902a72fffa5fed1/analysis/1422015743/) / utvideo-15.0.1-win.exe (https://www.virustotal.com/de/file/86a84bd3876a72f000649249b7190d768e8a836ef683646ce2ef03e5b161ed07/analysis/1422015928/)

Ongoing discussion (http://umezawa.dyndns.info/wordpress/?p=5292) on the japanese author's blog...

[LigH]

Version 15.0.2 appears to be clean (https://www.virustotal.com/en/file/1a6115abf5e8efb252f4a9652109a6e480354d43d3c09398133c263cf283bc4e/analysis/1422101384/).

[zerowalker]

Been reading and looking around how to Encode UTVideo with FFmpeg to Rec.709.

From my understanding this has been implemented in the Decoding, but not in the Encoding, or has that changed?

Cause i need to encode to Rec.709 via UT Video (not through color space conversions to "hack" through it).

[kolak]

Add -colorspace bt709 to your command.

[zerowalker]

Ah ok. Thanks

[zerowalker]

Is UT Video supposed to be slower than Lagarith at 60fps 1920x1200?
Cause it doesn't make sense, it's lagging on playback (i use Set for Decoding Speed),
compared to Lagarith which uses about 20% less CPU for the same clip.

Talking only decoding here, Encoding is different.

[Ignus2]

Is UT Video supposed to be slower than Lagarith at 60fps 1920x1200?
Cause it doesn't make sense, it's lagging on playback (i use Set for Decoding Speed),
compared to Lagarith which uses about 20% less CPU for the same clip.

Talking only decoding here, Encoding is different.

You are probably using the decoder from ffmpeg (either in Lav or MPC or something) and not the original UT decoders.
The ffmpeg variant is vastly inferior.

Greets,
I.

[zerowalker]

I am actually not doing that cause i thought the same.
I tried ffmpeg just in case, but it was so slow it's pretty much slideshow.

MagicYUV worked fined btw, huge difference in CPU Utilization.

EDIT:

UT Video used 50% (which is 100% as it only used 2 Threads).
MagicYUV uses about 15%.

Not sure if everything is as it should.
UT Video when i did tests before was fairly close go MagicYUV, but then again that wasn't at this resolution and fps.

[kolak]

If you encode utvideo with ffmpeg than even original decoder may be slow. There was some patch for utvideo and slices in ffmpeg. Make sure that you use latest ffmpeg and try adding -slices.
Even so ffmpeg version seams to be no near as good as original code.

Magicyuv is faster, though not 2x :)

[umezawa_takeshi]

Version 15.1.0 (http://umezawa.dyndns.info/wordpress/?p=5393) was released on 2015-02-28.

Bug fixes

Mac version do not use assembly language version routine.

Windows version is not affected by this problem.

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

[umezawa_takeshi]

Version 15.2.0 (http://umezawa.dyndns.info/wordpress/?p=5514) is released on 2015-04-25 JST.

New features

Added diagnostic log console.

Bug fixes

ULRA, ULRG: RGBA/RGB32 output from decoder is broken if encoded with "Optimize for compression ratio" and "Assume interlace video".


NOTICE TO MAC USERS: File name of QuickTime component is changed (old: utvideo.component, new: utv_qt.component). You have to delete old component file.

Run utv_logc to open diagnostic log console.

The bug exists in decoder. re-encoding is not necessary.

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

[umezawa_takeshi]

Source code repository of Ut Video Codec Suite was pushed to GitHub.
The URL is https://github.com/umezawatakeshi/utvideo

[kolak]

10/12bit RGB modes?
16bit I assume is tricky?

[umezawa_takeshi]

not yet at all.

[umezawa_takeshi]

Version 15.3.0 (http://umezawa.dyndns.info/wordpress/?p=5691) is released on 2015-09-22 JST.

Others

Removed MFT Codec.


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

[umezawa_takeshi]

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

Performance Improvements

Improved efficienty of QuickTime components.


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

[WorBry]

It's been a good while since I used UTVideo but having just installed version 15.4.0 I'm surprised to find that the RGB (ULRG) and RGBA (ULRA) formats don't appear in the list of VFW codecs under Compression in VirtualDub, as would be expected:

http://umezawa.dyndns.info/archive/utvideo/utvideo-15.4.0-readme.en.html

All I see listed are:

YUV420 BT.709 VCM (ULH0)
YUV422 BT.709 VCM (ULH2)
PRO YUV422 10bit (UQY2)

http://i.imgur.com/KIHoDTj.png

I'm running Win7 64-bit. Same thing with both 32-bit and 64-bit VDub 1.10.4.

Tried installing a earlier version of UTVideo 13.3.1, but still no RGB.

What gives ?

[ChiDragon]

Since you're also missing the BT.601 FOURCCs, did you open an HDYC video before looking at the Compression list?

What if you view the list with no video open in VDub?

[WorBry]

What if you view the list with no video open in VDub?

I see the same thing no matter what.

[WorBry]

Here's something interesting. I remembered a utility I used to use for checking and swapping installed VFW codecs (32bit) when I was working with DV - VCSwap. Installed that (surprised it even worked on Win7) and this is what it shows:

http://i.imgur.com/S0OcMTA.png

The "missing" fourcc's are listed there under 'active' vfw codecs, and all point to the utv-vcm.dll in the System32 folder, but they are not declared by "Description" as such.

I've no idea how to resolve that.

[Sparktank]

It's been a good while since I used UTVideo

Did you install only _or_ did you uninstall old version first then install new version?

[WorBry]

I should have been more specific; I meant it's been a good while, easily more than a year, since I used UTVideo for encoding RGB. I used it briefly maybe 6 weeks ago for encoding a couple of files HD files in YV12, but I honestly can't recall if the RGB codecs were listed then. That must have been version 15.3.0 as I kept copies of all the update exe files going back to 13.3.1 and the last one on file was 15.3.0. Seeing that RGB codecs were not listed and that an update was available, I just installed 15.4.0 over it (assumed 15.3.0), but still no RGB codecs. So I completely uninstalled 15.4.0 and tried again, but no joy. Uninstalled again and tried the earliest version I had on file (13.3.1), but still no RGB codecs. Uninstalled 13.3.1 and re-installed 15.4.0 again, and that's where it's at now. Nutty-crunch is that I just can't recall when the RGB codecs were last listed. Pathetic I know, but what to do?

[Sparktank]

I wasn't sure what version you installed prior, hence asking about uninstall/install process.

The installation notes in the Readme:
If version 10.2.0 or older is installed, you have to uninstall that version before you install this version.
Check. (done a multiple times)

If VCM codec is not registered properly, merge utvideo.reg in install destination with registry as a last resort. This file assumes Windows directory is C:\Windows.
For me, on Win7 (x64), the reg file can be found (installed to):
C:\Program Files\utvideo\utvideo.reg

Have you tried merging that reg file?

The reg file looks like this if you open in it in text editor:
REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32]
"VIDC.ULRA"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULRG"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULY0"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULY2"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULH0"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULH2"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.UQY2"="C:\\Windows\\system32\\utv_vcm.dll"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32]
"VIDC.ULRA"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULRG"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULY0"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULY2"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULH0"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.ULH2"="C:\\Windows\\system32\\utv_vcm.dll"
"VIDC.UQY2"="C:\\Windows\\system32\\utv_vcm.dll"

[WorBry]

For me, on Win7 (x64), the reg file can be found (installed to):
C:\Program Files\utvideo\utvideo.reg

Have you tried merging that reg file?

The reg file looks like this if you open in it in text editor:

Yes, I did try merging the reg file and it made no difference. Opening now the reg file in Notepad it is exactly the same as what you have posted.

If it's of any relevance at all, the UTVideo Global Configuration panel looked like this after fresh install of 15.4.0, with nothing ticked:

http://i.imgur.com/2PnHVD6.png

Grasping at straws, tried ticking either or both the config options, but made no difference.

[Sparktank]

What a conundrum.

Can't think of much else to do.
Except maybe uninstall again, but this time use something like CCleaner to clean all junk, clean the reg. Then reboot before installing newest version again (even right-click to install as Admin, even if single/only user on the PC).
And merge reg file again and reboot after.

Beyond that, I defer to other wizardry others can conjure up.

[WorBry]

A conundrum indeed.

Well I took your advice.

Uninstalled UTVideo 15.4.0, rebooted and ran CCleaner. Ran the CCleaner registry scan. There were two entries that I could see there relating to UTVideo:

One an "Application Path Issue" linked to the location of the UTVideo.exe installation file for version 13.3.1, which must have been retained from when I installed 13.3.1 from that location.

http://i.imgur.com/aPZNdZS.png

and other an Obsolete Software Key

http://i.imgur.com/lZAiPeH.png

Fixed (deleted) both of those, rebooted and re-installed UTVideo 15.4.0 (As Administrator). No change. Merged the reg file and rebooted - no change.

Made a full disc back-up. Repeated the process again, this time "fixing" all registry issue entries detected by the CCleaner registry scan. Installed UTVideo 15.4.0 again - no change. Merged the reg file and rebooted - no change.

Restored the full disc backup. I could have just made and restored a back-up of the registry, but I'm a bit twitchy about registry cleaners - had a bad experience on my last PC running XP.

So, I'm back to square one, minus those two fixed UTVideo registry entries.

Maybe the UTVideo developer could offer some advice if he's looking in.

[Sparktank]

Do you have UAC enabled or something?
If you download the installer and right-click it to see the properties dialogue box, does it show "unblock file" ?

[WorBry]

Yes, UAC is enabled and the UTVideo installer properties show the option to "Unblock File". But surely when the UAC screen "Do you want to allow the following program from an unknown publisher to make changes to this computer" pops up, clicking Yes does the same thing doesn't it?

[Ignus2]

The description and short name of a codec comes after loading the codec dll, not from the registry. If they are not there it means codec initialization with those fourccs fails in some way. Though that would be very strange.

Greets,
I.

[Sparktank]

Yes, UAC is enabled and the UTVideo installer properties show the option to "Unblock File". But surely when the UAC screen "Do you want to allow the following program from an unknown publisher to make changes to this computer" pops up, clicking Yes does the same thing doesn't it?

I would unblock the file before installing and go through the pop-up with UAC.
I think they're separate entities.

On my laptop, I had UAC disabled but would still need to unblock files from trusted soures to get full functionality.
With some AVS plugins/tools from here, if I forget to unblock the archive before extracting and try to run something, I would still get the pop-up even though UAC is disabled. (and I am single/only user as Admin)

When I experience issues with programs, I check the source installer (archive) and ensure that it has been ublocked.
Unblocking helps resolve most issues I have on that crummy laptop (also Win7 x64).

[WorBry]

Thanks for your continued efforts to find a solution.

Tried unblocking the installer file first, but I'm afraid it made no difference....still no pesky RGB codecs.

[WorBry]

The description and short name of a codec comes after loading the codec dll, not from the registry. If they are not there it means codec initialization with those fourccs fails in some way. Though that would be very strange.


And thanks for your reply also Ignus2. I'll take your word for that. Needless to say I have no idea what to do about it.

Reason why I'm 'revisiting' UTVideo is that I'm been tinkering with KDenlive in Linux (Kubuntu) of late, examining the various available input and output formats and their behavior with respect to YUV levels.

Testing some raw full-scale (0-255 luma) 1080/30p.mov clips from a Nikon camera, the KDenlive preset transcode formats (DNxHD, "Matroska.mkv" (HuffYuv)) compress to 16-235. Tried encoding these and some other formats (including UTVideo, FFV1) independently with FFMPEG. Despite setting the "full scale" pix_format flags yuvj422p and yuvj420p, FFMPEG auto-reverts to yuv422p and yuv420p (reporting pixel format incompatibility) and outputs 16-235 scale YUV. The only two formats I've got to work with the full scale pix_format flags are RawYUY2/YV12 and x264, and neither would be my choice for an input intermediate.

That said YV12/YUY2.avi encodes created with the vfw UTVideo work just fine and the "full scale" is respected in KDenLive. So there's an option there. As regards RGB transcode options, well (RawRGB aside), I suppose I could use FFMPEG UTvideo RGB for now, but it would be nice to have the vfw UTVideo RGB options.

Frustrating - so near and yet so far .

[umezawa_takeshi]

First, sorry for being late.

I have read preceding posts. What a conundrum.

As Ignus2 said, codec's short name and description are retrieved from DLL, not from registry. So it indicates initialization failure of codec.

Could you try following?:


Open command prompt and run C:\Program Files\utvideo\utv_logc.exe
This program is log viewer for Ut Video Codec Suite.
Run VDub and open "Select video compression" dialog.
You will see something like this in command prompt:
{0} Veedub64.exe[2108]: OPEN
{0} Veedub64.exe[2108]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
{0} Veedub64.exe[2108]: <utv_core> CPUID vendor="GenuineIntel"
{0} Veedub64.exe[2108]: <utv_core> CPUID procbrand=" Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz"
{0} Veedub64.exe[2108]: <utv_core> CPUID family=06H model=2AH
{0} Veedub64.exe[2108]: <utv_core> CPUID march="Sandy Bridge" (ID 00010004)
{0} Veedub64.exe[2108]: <utv_core> supports POPCNT
{0} Veedub64.exe[2108]: <utv_core> supports OSXSAVE
{0} Veedub64.exe[2108]: <utv_core> supports XMM/YMM state by OS
{0} Veedub64.exe[2108]: <utv_core> supports AVX1
{0} Veedub64.exe[2108]: <utv_core> supports SSE4.2
{0} Veedub64.exe[2108]: <utv_core> supports SSE4.1
{0} Veedub64.exe[2108]: <utv_core> supports SSSE3
{0} Veedub64.exe[2108]: <utv_core> supports SSE3
{0} Veedub64.exe[2108]: <utv_core> supports SSE2
{0} Veedub64.exe[2108]: <utv_core> DllMain(hModule=000007FEE2EF0000, dwReason=DLL_PROCESS_ATTACH, lpReserved=0000000000000000)
{0} Veedub64.exe[2108]: <utv_vcm > DllMain(hModule=000007FEF9640000, dwReason=DLL_PROCESS_ATTACH, lpReserved=0000000000000000)
{0} Veedub64.exe[2108]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{0} Veedub64.exe[2108]: <utv_vcm > 00000000003F7210 CVCMCodec::CVCMCodec(fccHandler=FFFFFFFF)
{0} Veedub64.exe[2108]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{0} Veedub64.exe[2108]: <utv_core> found utvf=00000000
{0} Veedub64.exe[2108]: <utv_vcm > 00000000003F7210 m_pCodec=00000000003987F0, TinyName="Dummy"
{0} Veedub64.exe[2108]: <utv_vcm > CVCMCodec::Open(icopen=000000000012EBD8, icopen->fccType=63646976, icopen->fccHandler=61726C75)
{0} Veedub64.exe[2108]: <utv_vcm > 00000000003F7230 CVCMCodec::CVCMCodec(fccHandler=41524C55)
{0} Veedub64.exe[2108]: <utv_core> CCodec::CreateInstance(utvf=554C5241)
{0} Veedub64.exe[2108]: <utv_core> found utvf=554C5241
{0} Veedub64.exe[2108]: <utv_core> 00000000028B0080 CCodecBase::CCodecBase(pszTinyName="ULRA", pszInterfaceName="VCM")
{0} Veedub64.exe[2108]: <utv_vcm > 00000000003F7230 m_pCodec=00000000028B0080, TinyName="ULRA"
{0} Veedub64.exe[2108]: <utv_vcm > 00000000003F7230 CVCMCodec::~CVCMCodec()
{0} Veedub64.exe[2108]: <utv_core> 00000000028B0080 CCodecBase::~CCodecBase()
{0} Veedub64.exe[2108]: <utv_vcm > 00000000003F7210 CVCMCodec::~CVCMCodec()
{0} Veedub64.exe[2108]: <utv_vcm > DllMain(hModule=000007FEF9640000, dwReason=DLL_PROCESS_DETACH, lpReserved=0000000000000000)
{0} Veedub64.exe[2108]: <utv_core> DllMain(hModule=000007FEE2EF0000, dwReason=DLL_PROCESS_DETACH, lpReserved=0000000000000000)
{0} Veedub64.exe[2108]: CLOSE
{1} Veedub64.exe[2108]: OPEN
{1} Veedub64.exe[2108]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
(snip)

Post all of that. (It should be very long. sorry)


I hope it shows a clew.

However, The process from loading DLL to retrieving codec information is completely same for all FourCC in Ut Video Codec Suite. I'm not sure that we can finally find solution...

[WorBry]

Thanks for responding to my cry for help :)

Here's the log file

C:\Program Files\utvideo>utv_logc.exe
{0} VirtualDub.exe[2536]: OPEN
{0} VirtualDub.exe[2536]: <utv_core> Ut Video Codec Suite 15.4.0 (x86)
{0} VirtualDub.exe[2536]: <utv_core> CPUID vendor="AuthenticAMD"
{0} VirtualDub.exe[2536]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Co
re Processor "
{0} VirtualDub.exe[2536]: <utv_core> CPUID family=15H model=02H
{0} VirtualDub.exe[2536]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{0} VirtualDub.exe[2536]: <utv_core> supports BMI1
{0} VirtualDub.exe[2536]: <utv_core> supports LZCNT
{0} VirtualDub.exe[2536]: <utv_core> supports POPCNT
{0} VirtualDub.exe[2536]: <utv_core> supports OSXSAVE
{0} VirtualDub.exe[2536]: <utv_core> supports XMM/YMM state by OS
{0} VirtualDub.exe[2536]: <utv_core> supports AVX1
{0} VirtualDub.exe[2536]: <utv_core> supports SSE4.2
{0} VirtualDub.exe[2536]: <utv_core> supports SSE4.1
{0} VirtualDub.exe[2536]: <utv_core> supports SSSE3
{0} VirtualDub.exe[2536]: <utv_core> supports SSE3
{0} VirtualDub.exe[2536]: <utv_core> supports SSE2
{0} VirtualDub.exe[2536]: <utv_core> DllMain(hModule=74800000, dwReason=DLL_PROC
ESS_ATTACH, lpReserved=00000000)
{0} VirtualDub.exe[2536]: <utv_vcm > DllMain(hModule=74E50000, dwReason=DLL_PROC
ESS_ATTACH, lpReserved=00000000)
{0} VirtualDub.exe[2536]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{0} VirtualDub.exe[2536]: <utv_vcm > 00291A58 CVCMCodec::CVCMCodec(fccHandler=FF
FFFFFF)
{0} VirtualDub.exe[2536]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{0} VirtualDub.exe[2536]: <utv_core> found utvf=00000000
{0} VirtualDub.exe[2536]: <utv_vcm > 00291A58 m_pCodec=00291A68, TinyName="Dumm
y"
{0} VirtualDub.exe[2536]: <utv_vcm > CVCMCodec::Open(icopen=0018EEE8, icopen->fc
cType=63646976, icopen->fccHandler=30686C75)
{0} VirtualDub.exe[2536]: <utv_vcm > 00291A78 CVCMCodec::CVCMCodec(fccHandler=30
484C55)
{0} VirtualDub.exe[2536]: <utv_core> CCodec::CreateInstance(utvf=554C4830)
{0} VirtualDub.exe[2536]: <utv_core> found utvf=554C4830
{0} VirtualDub.exe[2536]: <utv_core> 002A4E78 CCodecBase::CCodecBase(pszTinyName
="ULH0", pszInterfaceName="VCM")
{0} VirtualDub.exe[2536]: <utv_vcm > 00291A78 m_pCodec=002A4E78, TinyName="ULH0
"
{0} VirtualDub.exe[2536]: <utv_vcm > 00291A78 CVCMCodec::~CVCMCodec()
{0} VirtualDub.exe[2536]: <utv_core> 002A4E78 CCodecBase::~CCodecBase()
{0} VirtualDub.exe[2536]: <utv_vcm > 00291A58 CVCMCodec::~CVCMCodec()
{0} VirtualDub.exe[2536]: <utv_vcm > DllMain(hModule=74E50000, dwReason=DLL_PROC
ESS_DETACH, lpReserved=00000000)
{0} VirtualDub.exe[2536]: <utv_core> DllMain(hModule=74800000, dwReason=DLL_PROC
ESS_DETACH, lpReserved=00000000)
{0} VirtualDub.exe[2536]: CLOSE
{1} VirtualDub.exe[2536]: OPEN
{1} VirtualDub.exe[2536]: <utv_core> Ut Video Codec Suite 15.4.0 (x86)
{1} VirtualDub.exe[2536]: <utv_core> CPUID vendor="AuthenticAMD"
{1} VirtualDub.exe[2536]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Co
re Processor "
{1} VirtualDub.exe[2536]: <utv_core> CPUID family=15H model=02H
{1} VirtualDub.exe[2536]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{1} VirtualDub.exe[2536]: <utv_core> supports BMI1
{1} VirtualDub.exe[2536]: <utv_core> supports LZCNT
{1} VirtualDub.exe[2536]: <utv_core> supports POPCNT
{1} VirtualDub.exe[2536]: <utv_core> supports OSXSAVE
{1} VirtualDub.exe[2536]: <utv_core> supports XMM/YMM state by OS
{1} VirtualDub.exe[2536]: <utv_core> supports AVX1
{1} VirtualDub.exe[2536]: <utv_core> supports SSE4.2
{1} VirtualDub.exe[2536]: <utv_core> supports SSE4.1
{1} VirtualDub.exe[2536]: <utv_core> supports SSSE3
{1} VirtualDub.exe[2536]: <utv_core> supports SSE3
{1} VirtualDub.exe[2536]: <utv_core> supports SSE2
{1} VirtualDub.exe[2536]: <utv_core> DllMain(hModule=747E0000, dwReason=DLL_PROC
ESS_ATTACH, lpReserved=00000000)
{1} VirtualDub.exe[2536]: <utv_vcm > DllMain(hModule=74820000, dwReason=DLL_PROC
ESS_ATTACH, lpReserved=00000000)
{1} VirtualDub.exe[2536]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{1} VirtualDub.exe[2536]: <utv_vcm > 00291A58 CVCMCodec::CVCMCodec(fccHandler=FF
FFFFFF)
{1} VirtualDub.exe[2536]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{1} VirtualDub.exe[2536]: <utv_core> found utvf=00000000
{1} VirtualDub.exe[2536]: <utv_vcm > 00291A58 m_pCodec=00291A68, TinyName="Dumm
y"
{1} VirtualDub.exe[2536]: <utv_vcm > CVCMCodec::Open(icopen=0018EEE8, icopen->fc
cType=63646976, icopen->fccHandler=32686C75)
{1} VirtualDub.exe[2536]: <utv_vcm > 00291A78 CVCMCodec::CVCMCodec(fccHandler=32
484C55)
{1} VirtualDub.exe[2536]: <utv_core> CCodec::CreateInstance(utvf=554C4832)
{1} VirtualDub.exe[2536]: <utv_core> found utvf=554C4832
{1} VirtualDub.exe[2536]: <utv_core> 002A43F8 CCodecBase::CCodecBase(pszTinyName
="ULH2", pszInterfaceName="VCM")
{1} VirtualDub.exe[2536]: <utv_vcm > 00291A78 m_pCodec=002A43F8, TinyName="ULH2
"
{1} VirtualDub.exe[2536]: <utv_vcm > 00291A78 CVCMCodec::~CVCMCodec()
{1} VirtualDub.exe[2536]: <utv_core> 002A43F8 CCodecBase::~CCodecBase()
{1} VirtualDub.exe[2536]: <utv_vcm > 00291A58 CVCMCodec::~CVCMCodec()
{1} VirtualDub.exe[2536]: <utv_vcm > DllMain(hModule=74820000, dwReason=DLL_PROC
ESS_DETACH, lpReserved=00000000)
{1} VirtualDub.exe[2536]: <utv_core> DllMain(hModule=747E0000, dwReason=DLL_PROC
ESS_DETACH, lpReserved=00000000)
{1} VirtualDub.exe[2536]: CLOSE
{2} VirtualDub.exe[2536]: OPEN
{2} VirtualDub.exe[2536]: <utv_core> Ut Video Codec Suite 15.4.0 (x86)
{2} VirtualDub.exe[2536]: <utv_core> CPUID vendor="AuthenticAMD"
{2} VirtualDub.exe[2536]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Co
re Processor "
{2} VirtualDub.exe[2536]: <utv_core> CPUID family=15H model=02H
{2} VirtualDub.exe[2536]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{2} VirtualDub.exe[2536]: <utv_core> supports BMI1
{2} VirtualDub.exe[2536]: <utv_core> supports LZCNT
{2} VirtualDub.exe[2536]: <utv_core> supports POPCNT
{2} VirtualDub.exe[2536]: <utv_core> supports OSXSAVE
{2} VirtualDub.exe[2536]: <utv_core> supports XMM/YMM state by OS
{2} VirtualDub.exe[2536]: <utv_core> supports AVX1
{2} VirtualDub.exe[2536]: <utv_core> supports SSE4.2
{2} VirtualDub.exe[2536]: <utv_core> supports SSE4.1
{2} VirtualDub.exe[2536]: <utv_core> supports SSSE3
{2} VirtualDub.exe[2536]: <utv_core> supports SSE3
{2} VirtualDub.exe[2536]: <utv_core> supports SSE2
{2} VirtualDub.exe[2536]: <utv_core> DllMain(hModule=74800000, dwReason=DLL_PROC
ESS_ATTACH, lpReserved=00000000)
{2} VirtualDub.exe[2536]: <utv_vcm > DllMain(hModule=74E50000, dwReason=DLL_PROC
ESS_ATTACH, lpReserved=00000000)
{2} VirtualDub.exe[2536]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{2} VirtualDub.exe[2536]: <utv_vcm > 00291998 CVCMCodec::CVCMCodec(fccHandler=FF
FFFFFF)
{2} VirtualDub.exe[2536]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{2} VirtualDub.exe[2536]: <utv_core> found utvf=00000000
{2} VirtualDub.exe[2536]: <utv_vcm > 00291998 m_pCodec=002919A8, TinyName="Dumm
y"
{2} VirtualDub.exe[2536]: <utv_vcm > CVCMCodec::Open(icopen=0018EEE8, icopen->fc
cType=63646976, icopen->fccHandler=32797175)
{2} VirtualDub.exe[2536]: <utv_vcm > 00291A58 CVCMCodec::CVCMCodec(fccHandler=32
595155)
{2} VirtualDub.exe[2536]: <utv_core> CCodec::CreateInstance(utvf=55515932)
{2} VirtualDub.exe[2536]: <utv_core> found utvf=55515932
{2} VirtualDub.exe[2536]: <utv_core> 002A8468 CCodecBase::CCodecBase(pszTinyName
="UQY2", pszInterfaceName="VCM")
{2} VirtualDub.exe[2536]: <utv_vcm > 00291A58 m_pCodec=002A8468, TinyName="UQY2
"
{2} VirtualDub.exe[2536]: <utv_vcm > 00291A58 CVCMCodec::~CVCMCodec()
{2} VirtualDub.exe[2536]: <utv_core> 002A8468 CCodecBase::~CCodecBase()
{2} VirtualDub.exe[2536]: <utv_vcm > 00291998 CVCMCodec::~CVCMCodec()
{2} VirtualDub.exe[2536]: <utv_vcm > DllMain(hModule=74E50000, dwReason=DLL_PROC
ESS_DETACH, lpReserved=00000000)
{2} VirtualDub.exe[2536]: <utv_core> DllMain(hModule=74800000, dwReason=DLL_PROC
ESS_DETACH, lpReserved=00000000)
{2} VirtualDub.exe[2536]: CLOSE

[WorBry]

And here's the log file when opening VirtualDub 64-bit, which I don't normally use and is located in a folder on a separate volume from the C:\ drive

C:\Program Files\utvideo>utv_logc.exe
{0} Veedub64.exe[3296]: OPEN
{0} Veedub64.exe[3296]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
{0} Veedub64.exe[3296]: <utv_core> CPUID vendor="AuthenticAMD"
{0} Veedub64.exe[3296]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Core
Processor "
{0} Veedub64.exe[3296]: <utv_core> CPUID family=15H model=02H
{0} Veedub64.exe[3296]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{0} Veedub64.exe[3296]: <utv_core> supports BMI1
{0} Veedub64.exe[3296]: <utv_core> supports LZCNT
{0} Veedub64.exe[3296]: <utv_core> supports POPCNT
{0} Veedub64.exe[3296]: <utv_core> supports OSXSAVE
{0} Veedub64.exe[3296]: <utv_core> supports XMM/YMM state by OS
{0} Veedub64.exe[3296]: <utv_core> supports AVX1
{0} Veedub64.exe[3296]: <utv_core> supports SSE4.2
{0} Veedub64.exe[3296]: <utv_core> supports SSE4.1
{0} Veedub64.exe[3296]: <utv_core> supports SSSE3
{0} Veedub64.exe[3296]: <utv_core> supports SSE3
{0} Veedub64.exe[3296]: <utv_core> supports SSE2
{0} Veedub64.exe[3296]: <utv_core> DllMain(hModule=000007FEF0C30000, dwReason=DL
L_PROCESS_ATTACH, lpReserved=0000000000000000)
{0} Veedub64.exe[3296]: <utv_vcm > DllMain(hModule=000007FEF7D00000, dwReason=DL
L_PROCESS_ATTACH, lpReserved=0000000000000000)
{0} Veedub64.exe[3296]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{0} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 CVCMCodec::CVCMCodec(fccHand
ler=FFFFFFFF)
{0} Veedub64.exe[3296]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{0} Veedub64.exe[3296]: <utv_core> found utvf=00000000
{0} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 m_pCodec=00000000003328C0,
TinyName="Dummy"
{0} Veedub64.exe[3296]: <utv_vcm > CVCMCodec::Open(icopen=000000000012E8B8, icop
en->fccType=63646976, icopen->fccHandler=30686C75)
{0} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 CVCMCodec::CVCMCodec(fccHand
ler=30484C55)
{0} Veedub64.exe[3296]: <utv_core> CCodec::CreateInstance(utvf=554C4830)
{0} Veedub64.exe[3296]: <utv_core> found utvf=554C4830
{0} Veedub64.exe[3296]: <utv_core> 0000000000341FA0 CCodecBase::CCodecBase(pszTi
nyName="ULH0", pszInterfaceName="VCM")
{0} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 m_pCodec=0000000000341FA0,
TinyName="ULH0"
{0} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 CVCMCodec::~CVCMCodec()
{0} Veedub64.exe[3296]: <utv_core> 0000000000341FA0 CCodecBase::~CCodecBase()
{0} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 CVCMCodec::~CVCMCodec()
{0} Veedub64.exe[3296]: <utv_vcm > DllMain(hModule=000007FEF7D00000, dwReason=DL
L_PROCESS_DETACH, lpReserved=0000000000000000)
{0} Veedub64.exe[3296]: <utv_core> DllMain(hModule=000007FEF0C30000, dwReason=DL
L_PROCESS_DETACH, lpReserved=0000000000000000)
{0} Veedub64.exe[3296]: CLOSE
{1} Veedub64.exe[3296]: OPEN
{1} Veedub64.exe[3296]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
{1} Veedub64.exe[3296]: <utv_core> CPUID vendor="AuthenticAMD"
{1} Veedub64.exe[3296]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Core
Processor "
{1} Veedub64.exe[3296]: <utv_core> CPUID family=15H model=02H
{1} Veedub64.exe[3296]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{1} Veedub64.exe[3296]: <utv_core> supports BMI1
{1} Veedub64.exe[3296]: <utv_core> supports LZCNT
{1} Veedub64.exe[3296]: <utv_core> supports POPCNT
{1} Veedub64.exe[3296]: <utv_core> supports OSXSAVE
{1} Veedub64.exe[3296]: <utv_core> supports XMM/YMM state by OS
{1} Veedub64.exe[3296]: <utv_core> supports AVX1
{1} Veedub64.exe[3296]: <utv_core> supports SSE4.2
{1} Veedub64.exe[3296]: <utv_core> supports SSE4.1
{1} Veedub64.exe[3296]: <utv_core> supports SSSE3
{1} Veedub64.exe[3296]: <utv_core> supports SSE3
{1} Veedub64.exe[3296]: <utv_core> supports SSE2
{1} Veedub64.exe[3296]: <utv_core> DllMain(hModule=000007FEF0BE0000, dwReason=DL
L_PROCESS_ATTACH, lpReserved=0000000000000000)
{1} Veedub64.exe[3296]: <utv_vcm > DllMain(hModule=000007FEF7CE0000, dwReason=DL
L_PROCESS_ATTACH, lpReserved=0000000000000000)
{1} Veedub64.exe[3296]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{1} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 CVCMCodec::CVCMCodec(fccHand
ler=FFFFFFFF)
{1} Veedub64.exe[3296]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{1} Veedub64.exe[3296]: <utv_core> found utvf=00000000
{1} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 m_pCodec=00000000003328C0,
TinyName="Dummy"
{1} Veedub64.exe[3296]: <utv_vcm > CVCMCodec::Open(icopen=000000000012E8B8, icop
en->fccType=63646976, icopen->fccHandler=32686C75)
{1} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 CVCMCodec::CVCMCodec(fccHand
ler=32484C55)
{1} Veedub64.exe[3296]: <utv_core> CCodec::CreateInstance(utvf=554C4832)
{1} Veedub64.exe[3296]: <utv_core> found utvf=554C4832
{1} Veedub64.exe[3296]: <utv_core> 0000000000341410 CCodecBase::CCodecBase(pszTi
nyName="ULH2", pszInterfaceName="VCM")
{1} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 m_pCodec=0000000000341410,
TinyName="ULH2"
{1} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 CVCMCodec::~CVCMCodec()
{1} Veedub64.exe[3296]: <utv_core> 0000000000341410 CCodecBase::~CCodecBase()
{1} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 CVCMCodec::~CVCMCodec()
{1} Veedub64.exe[3296]: <utv_vcm > DllMain(hModule=000007FEF7CE0000, dwReason=DL
L_PROCESS_DETACH, lpReserved=0000000000000000)
{1} Veedub64.exe[3296]: <utv_core> DllMain(hModule=000007FEF0BE0000, dwReason=DL
L_PROCESS_DETACH, lpReserved=0000000000000000)
{1} Veedub64.exe[3296]: CLOSE
{2} Veedub64.exe[3296]: OPEN
{2} Veedub64.exe[3296]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
{2} Veedub64.exe[3296]: <utv_core> CPUID vendor="AuthenticAMD"
{2} Veedub64.exe[3296]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Core
Processor "
{2} Veedub64.exe[3296]: <utv_core> CPUID family=15H model=02H
{2} Veedub64.exe[3296]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{2} Veedub64.exe[3296]: <utv_core> supports BMI1
{2} Veedub64.exe[3296]: <utv_core> supports LZCNT
{2} Veedub64.exe[3296]: <utv_core> supports POPCNT
{2} Veedub64.exe[3296]: <utv_core> supports OSXSAVE
{2} Veedub64.exe[3296]: <utv_core> supports XMM/YMM state by OS
{2} Veedub64.exe[3296]: <utv_core> supports AVX1
{2} Veedub64.exe[3296]: <utv_core> supports SSE4.2
{2} Veedub64.exe[3296]: <utv_core> supports SSE4.1
{2} Veedub64.exe[3296]: <utv_core> supports SSSE3
{2} Veedub64.exe[3296]: <utv_core> supports SSE3
{2} Veedub64.exe[3296]: <utv_core> supports SSE2
{2} Veedub64.exe[3296]: <utv_core> DllMain(hModule=000007FEF0C30000, dwReason=DL
L_PROCESS_ATTACH, lpReserved=0000000000000000)
{2} Veedub64.exe[3296]: <utv_vcm > DllMain(hModule=000007FEF7D00000, dwReason=DL
L_PROCESS_ATTACH, lpReserved=0000000000000000)
{2} Veedub64.exe[3296]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{2} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 CVCMCodec::CVCMCodec(fccHand
ler=FFFFFFFF)
{2} Veedub64.exe[3296]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{2} Veedub64.exe[3296]: <utv_core> found utvf=00000000
{2} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 m_pCodec=00000000003328C0,
TinyName="Dummy"
{2} Veedub64.exe[3296]: <utv_vcm > CVCMCodec::Open(icopen=000000000012E8B8, icop
en->fccType=63646976, icopen->fccHandler=32797175)
{2} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 CVCMCodec::CVCMCodec(fccHand
ler=32595155)
{2} Veedub64.exe[3296]: <utv_core> CCodec::CreateInstance(utvf=55515932)
{2} Veedub64.exe[3296]: <utv_core> found utvf=55515932
{2} Veedub64.exe[3296]: <utv_core> 00000000003420A0 CCodecBase::CCodecBase(pszTi
nyName="UQY2", pszInterfaceName="VCM")
{2} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 m_pCodec=00000000003420A0,
TinyName="UQY2"
{2} Veedub64.exe[3296]: <utv_vcm > 0000000000321640 CVCMCodec::~CVCMCodec()
{2} Veedub64.exe[3296]: <utv_core> 00000000003420A0 CCodecBase::~CCodecBase()
{2} Veedub64.exe[3296]: <utv_vcm > 0000000000321620 CVCMCodec::~CVCMCodec()
{2} Veedub64.exe[3296]: <utv_vcm > DllMain(hModule=000007FEF7D00000, dwReason=DL
L_PROCESS_DETACH, lpReserved=0000000000000000)
{2} Veedub64.exe[3296]: <utv_core> DllMain(hModule=000007FEF0C30000, dwReason=DL
L_PROCESS_DETACH, lpReserved=0000000000000000)
{2} Veedub64.exe[3296]: CLOSE

[WorBry]

And if it provides any other clues, here's the log file when I open Corel VideoStudio Pro x8 (64-bit) which is the NLE I use. In the Project Setting options for creating custom DV/AVI profiles, UTVideo is listed as one of the available (64-bit) VFW codec options. But like VirtualDub, the RGB fourcc's do not show up there either.

C:\Program Files\utvideo>utv_logc.exe
{0} vstudio.exe[4912]: OPEN
{0} vstudio.exe[4912]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
{0} vstudio.exe[4912]: <utv_core> CPUID vendor="AuthenticAMD"
{0} vstudio.exe[4912]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Core
Processor "
{0} vstudio.exe[4912]: <utv_core> CPUID family=15H model=02H
{0} vstudio.exe[4912]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{0} vstudio.exe[4912]: <utv_core> supports BMI1
{0} vstudio.exe[4912]: <utv_core> supports LZCNT
{0} vstudio.exe[4912]: <utv_core> supports POPCNT
{0} vstudio.exe[4912]: <utv_core> supports OSXSAVE
{0} vstudio.exe[4912]: <utv_core> supports XMM/YMM state by OS
{0} vstudio.exe[4912]: <utv_core> supports AVX1
{0} vstudio.exe[4912]: <utv_core> supports SSE4.2
{0} vstudio.exe[4912]: <utv_core> supports SSE4.1
{0} vstudio.exe[4912]: <utv_core> supports SSSE3
{0} vstudio.exe[4912]: <utv_core> supports SSE3
{0} vstudio.exe[4912]: <utv_core> supports SSE2
{0} vstudio.exe[4912]: <utv_core> DllMain(hModule=000007FEED7D0000, dwReason=DLL
_PROCESS_ATTACH, lpReserved=0000000000000000)
{0} vstudio.exe[4912]: <utv_vcm > DllMain(hModule=000007FEED820000, dwReason=DLL
_PROCESS_ATTACH, lpReserved=0000000000000000)
{0} vstudio.exe[4912]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78620 CVCMCodec::CVCMCodec(fccHandl
er=FFFFFFFF)
{0} vstudio.exe[4912]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{0} vstudio.exe[4912]: <utv_core> found utvf=00000000
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78620 m_pCodec=0000000004CCEC70, T
inyName="Dummy"
{0} vstudio.exe[4912]: <utv_vcm > CVCMCodec::Open(icopen=000000000012BDE8, icope
n->fccType=63646976, icopen->fccHandler=30686C75)
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 CVCMCodec::CVCMCodec(fccHandl
er=30484C55)
{0} vstudio.exe[4912]: <utv_core> CCodec::CreateInstance(utvf=554C4830)
{0} vstudio.exe[4912]: <utv_core> found utvf=554C4830
{0} vstudio.exe[4912]: <utv_core> 0000000004E67B70 CCodecBase::CCodecBase(pszTin
yName="ULH0", pszInterfaceName="VCM")
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 m_pCodec=0000000004E67B70, T
inyName="ULH0"
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 CVCMCodec::CompressGetFormat(
pbihIn=0000000004E76F50, pbihOut=0000000004E77400)
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=8, biCompression=00000000, biSizeImage
=76800
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 CVCMCodec::CompressGetFormat(
pbihIn=0000000004E76F50, pbihOut=0000000004E77400)
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=16, biCompression=00000000, biSizeImag
e=153600
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 CVCMCodec::CompressGetFormat(
pbihIn=0000000004E76F50, pbihOut=0000000004E77400)
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=24, biCompression=00000000, biSizeImag
e=230400
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78640 CVCMCodec::~CVCMCodec()
{0} vstudio.exe[4912]: <utv_core> 0000000004E67B70 CCodecBase::~CCodecBase()
{0} vstudio.exe[4912]: <utv_vcm > 0000000004E78620 CVCMCodec::~CVCMCodec()
{0} vstudio.exe[4912]: <utv_vcm > DllMain(hModule=000007FEED820000, dwReason=DLL
_PROCESS_DETACH, lpReserved=0000000000000000)
{0} vstudio.exe[4912]: <utv_core> DllMain(hModule=000007FEED7D0000, dwReason=DLL
_PROCESS_DETACH, lpReserved=0000000000000000)
{0} vstudio.exe[4912]: CLOSE
{1} vstudio.exe[4912]: OPEN
{1} vstudio.exe[4912]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
{1} vstudio.exe[4912]: <utv_core> CPUID vendor="AuthenticAMD"
{1} vstudio.exe[4912]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Core
Processor "
{1} vstudio.exe[4912]: <utv_core> CPUID family=15H model=02H
{1} vstudio.exe[4912]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{1} vstudio.exe[4912]: <utv_core> supports BMI1
{1} vstudio.exe[4912]: <utv_core> supports LZCNT
{1} vstudio.exe[4912]: <utv_core> supports POPCNT
{1} vstudio.exe[4912]: <utv_core> supports OSXSAVE
{1} vstudio.exe[4912]: <utv_core> supports XMM/YMM state by OS
{1} vstudio.exe[4912]: <utv_core> supports AVX1
{1} vstudio.exe[4912]: <utv_core> supports SSE4.2
{1} vstudio.exe[4912]: <utv_core> supports SSE4.1
{1} vstudio.exe[4912]: <utv_core> supports SSSE3
{1} vstudio.exe[4912]: <utv_core> supports SSE3
{1} vstudio.exe[4912]: <utv_core> supports SSE2
{1} vstudio.exe[4912]: <utv_core> DllMain(hModule=000007FEED7B0000, dwReason=DLL
_PROCESS_ATTACH, lpReserved=0000000000000000)
{1} vstudio.exe[4912]: <utv_vcm > DllMain(hModule=000007FEED800000, dwReason=DLL
_PROCESS_ATTACH, lpReserved=0000000000000000)
{1} vstudio.exe[4912]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78720 CVCMCodec::CVCMCodec(fccHandl
er=FFFFFFFF)
{1} vstudio.exe[4912]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{1} vstudio.exe[4912]: <utv_core> found utvf=00000000
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78720 m_pCodec=0000000004CCEC70, T
inyName="Dummy"
{1} vstudio.exe[4912]: <utv_vcm > CVCMCodec::Open(icopen=000000000012BDE8, icope
n->fccType=63646976, icopen->fccHandler=32686C75)
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CVCMCodec(fccHandl
er=32484C55)
{1} vstudio.exe[4912]: <utv_core> CCodec::CreateInstance(utvf=554C4832)
{1} vstudio.exe[4912]: <utv_core> found utvf=554C4832
{1} vstudio.exe[4912]: <utv_core> 0000000004E67B70 CCodecBase::CCodecBase(pszTin
yName="ULH2", pszInterfaceName="VCM")
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 m_pCodec=0000000004E67B70, T
inyName="ULH2"
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=0000000004E76F50, pbihOut=0000000004E77400)
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=8, biCompression=00000000, biSizeImage
=76800
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=0000000004E76F50, pbihOut=0000000004E77400)
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=16, biCompression=00000000, biSizeImag
e=153600
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=0000000004E76F50, pbihOut=0000000004E77400)
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=24, biCompression=00000000, biSizeImag
e=230400
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::~CVCMCodec()
{1} vstudio.exe[4912]: <utv_core> 0000000004E67B70 CCodecBase::~CCodecBase()
{1} vstudio.exe[4912]: <utv_vcm > 0000000004E78720 CVCMCodec::~CVCMCodec()
{1} vstudio.exe[4912]: <utv_vcm > DllMain(hModule=000007FEED800000, dwReason=DLL
_PROCESS_DETACH, lpReserved=0000000000000000)
{1} vstudio.exe[4912]: <utv_core> DllMain(hModule=000007FEED7B0000, dwReason=DLL
_PROCESS_DETACH, lpReserved=0000000000000000)
{1} vstudio.exe[4912]: CLOSE
{2} vstudio.exe[4912]: OPEN
{2} vstudio.exe[4912]: <utv_core> Ut Video Codec Suite 15.4.0 (x64)
{2} vstudio.exe[4912]: <utv_core> CPUID vendor="AuthenticAMD"
{2} vstudio.exe[4912]: <utv_core> CPUID procbrand="AMD FX(tm)-6300 Six-Core
Processor "
{2} vstudio.exe[4912]: <utv_core> CPUID family=15H model=02H
{2} vstudio.exe[4912]: <utv_core> CPUID march="Unknown" (ID FFFFFFFF)
{2} vstudio.exe[4912]: <utv_core> supports BMI1
{2} vstudio.exe[4912]: <utv_core> supports LZCNT
{2} vstudio.exe[4912]: <utv_core> supports POPCNT
{2} vstudio.exe[4912]: <utv_core> supports OSXSAVE
{2} vstudio.exe[4912]: <utv_core> supports XMM/YMM state by OS
{2} vstudio.exe[4912]: <utv_core> supports AVX1
{2} vstudio.exe[4912]: <utv_core> supports SSE4.2
{2} vstudio.exe[4912]: <utv_core> supports SSE4.1
{2} vstudio.exe[4912]: <utv_core> supports SSSE3
{2} vstudio.exe[4912]: <utv_core> supports SSE3
{2} vstudio.exe[4912]: <utv_core> supports SSE2
{2} vstudio.exe[4912]: <utv_core> DllMain(hModule=000007FEED7D0000, dwReason=DLL
_PROCESS_ATTACH, lpReserved=0000000000000000)
{2} vstudio.exe[4912]: <utv_vcm > DllMain(hModule=000007FEED820000, dwReason=DLL
_PROCESS_ATTACH, lpReserved=0000000000000000)
{2} vstudio.exe[4912]: <utv_vcm > CVCMCodec::Open(icopen=NULL)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78720 CVCMCodec::CVCMCodec(fccHandl
er=FFFFFFFF)
{2} vstudio.exe[4912]: <utv_core> CCodec::CreateInstance(utvf=00000000)
{2} vstudio.exe[4912]: <utv_core> found utvf=00000000
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78720 m_pCodec=0000000004CCEC70, T
inyName="Dummy"
{2} vstudio.exe[4912]: <utv_vcm > CVCMCodec::Open(icopen=000000000012BDE8, icope
n->fccType=63646976, icopen->fccHandler=32797175)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CVCMCodec(fccHandl
er=32595155)
{2} vstudio.exe[4912]: <utv_core> CCodec::CreateInstance(utvf=55515932)
{2} vstudio.exe[4912]: <utv_core> found utvf=55515932
{2} vstudio.exe[4912]: <utv_core> 000000000E097FD0 CCodecBase::CCodecBase(pszTin
yName="UQY2", pszInterfaceName="VCM")
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 m_pCodec=000000000E097FD0, T
inyName="UQY2"
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=000000000E0801B0, pbihOut=000000000E080660)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=8, biCompression=00000000, biSizeImage
=76800
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=000000000E0801B0, pbihOut=000000000E080660)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=16, biCompression=00000000, biSizeImag
e=153600
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=000000000E0801B0, pbihOut=000000000E080660)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
320, biHeight=240, biPlanes=1, biBitCount=24, biCompression=00000000, biSizeImag
e=230400
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=000000000E0801B0, pbihOut=000000000E080660)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
720, biHeight=480, biPlanes=1, biBitCount=8, biCompression=00000000, biSizeImage
=345600
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=000000000E0801B0, pbihOut=000000000E080660)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
720, biHeight=480, biPlanes=1, biBitCount=16, biCompression=00000000, biSizeImag
e=691200
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::CompressGetFormat(
pbihIn=000000000E0801B0, pbihOut=000000000E080660)
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 pbihIn : biSize=40, biWidth=
720, biHeight=480, biPlanes=1, biBitCount=24, biCompression=00000000, biSizeImag
e=1036800
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78740 CVCMCodec::~CVCMCodec()
{2} vstudio.exe[4912]: <utv_core> 000000000E097FD0 CCodecBase::~CCodecBase()
{2} vstudio.exe[4912]: <utv_vcm > 0000000004E78720 CVCMCodec::~CVCMCodec()
{2} vstudio.exe[4912]: <utv_vcm > DllMain(hModule=000007FEED820000, dwReason=DLL
_PROCESS_DETACH, lpReserved=0000000000000000)
{2} vstudio.exe[4912]: <utv_core> DllMain(hModule=000007FEED7D0000, dwReason=DLL
_PROCESS_DETACH, lpReserved=0000000000000000)
{2} vstudio.exe[4912]: CLOSE

[umezawa_takeshi]

According to log output,


codec opening request is not sent to DLL
In addition, DLL is not loaded


It indicates that Windows give up opening codec before loading DLL of Ut Video Codec Suite. hmm...

BTW, according to the output of VCSwap that you posted before, you have installed ffdshow. Earlier version of ffdshow (or libavcodec, on which ffdshow is based) have implementation of ULRA, ULRG, ULY2 and ULY0, but don't have ULH2, ULH0 and UQY2. (I don't know that your version 1.3.4524.0 have implementation of ULH2 and ULH0). Are there any relationship...?

[WorBry]

Thanks.

I'm not sure I understand what association you are suggesting might be related to the UTVideo issue.

Yes, I have CLSID's Rev4525 (Nov 17 2013) of FFDShow installed. Again, I can't recall when it was first installed, but it's been quite a while. Can't see any mention of UTVideo FourCC's there in the FFDShow "VFW Configuration" or "Video Decoder Configuration" codec listings. So I'm not really sure what you are referring to.

I've tried uninstalling both FFDShow and UTVideo 15.4.0, and then re-installing 15.4.0 (after a clean-up with CCleaner) but it's made no difference.

If it's of any relevance at all, I recall (about 6 weeks back) installing 64-bit versions of FFDShow I had on file (rev4531_20140628_x64 and CLSID's rev4533_20140929_clsid_x64) to do some tests in Corel VideoStudio Pro x8 (64-bit) but couldn't proceed because FFDShow didn't appear at all in the list of available 64-bit VFW codecs in the VSProx8 Project Configuration settings. Just why, I don't know. But instead of uninstalling FFDShow-x64, I just rolled-back to a system back-up I'd made beforehand, so I can't see how that episode could have messed things up for UTVIdeo in some way.

Grasping at straws here. Anything else to try ?

EDIT: Plus, I've just tried restoring a full disc back-up (Acronis True Image) of the Win7 x64 system from 25th Nov 2015 - so before all of that. There I find UTVideo 13.3.1 was installed , but the situation was the same. The only FourCC's listed in VDub were:

YUV420 BT.709 VCM (ULH0)
YUV422 BT.709 VCM (ULH2)
PRO YUV422 10bit (UQY2)

Tried uninstalling 13.3.1, followed by a reboot and CCleaner clean-up before installing 15.4.0, but no change.

I have earlier system back-ups, but this was the first good backup after some hardware/network changes and I don't really want to go through that episode again. I've now returned the system to how it was. I never restore anything with System Restore by the way, only back-ups.

So what to do? Is this possibly a bug that I didn't pick-up on earlier?

[Ignus2]

According to log output,


codec opening request is not sent to DLL
In addition, DLL is not loaded


It indicates that Windows give up opening codec before loading DLL of Ut Video Codec Suite. hmm...

BTW, according to the output of VCSwap that you posted before, you have installed ffdshow. Earlier version of ffdshow (or libavcodec, on which ffdshow is based) have implementation of ULRA, ULRG, ULY2 and ULY0, but don't have ULH2, ULH0 and UQY2. (I don't know that your version 1.3.4524.0 have implementation of ULH2 and ULH0). Are there any relationship...?

That's a clue!
Worbry, you do have ffdshow vfw installed. In your screenshot of codecs, I can see ff_vfw.dll, most certainly that's your problem.
Either delete the registry key for it or delete the dll itself.
This is tricky for 32 bit variants, as the registry and system32 folder is redirected for them.
I suggest you delete these two files:

C:\Windows\system32\ff_vfw.dll. (the 64-bit codec)
C:\Windows\SysWow64\ff_vfw.dll (the 32-bit codec)

EDIT: The location of those DLLs might be somewhere else, I don't know where ffdshow puts them. If they are not there, search for them or look in the registry. Also, it's best to delete the registry keys for ff_vfw.dll too (both).

Make sure to use a 64-bit file manager, as 32-bit programs are redirected to SysWow64.

Greets,
I.

[WorBry]

Thanks Ignus2,

Sorry for my ignorance, for all to see, but I tried uninstalling FFDShow - wouldn't that do the same ?

And whats a "64-bit file manager" ?

[Ignus2]

Thanks Ignus2,

Sorry for my ignorance, for all to see, but I tried uninstalling FFDShow - wouldn't that do the same ?

And whats a "64-bit file manager" ?

It should, but as the screenshot shows, it didn't (or system restore messed up somehow).

Just use Windows explorer. (Total Commander 32-bit edition for example is not a 64-bit file manager.)

Greets,
I.

[LigH]

People old enough to remember the "Norton Commander" (but not excluding younger people) may also like the Far manager (http://www.farmanager.com), which is also available in 32 and 64 bit. It is a real text mode application, adapting to any arbitrary console window size. There are several plugins available, e.g. a Registry browser too. And it doesn't camouflage system directories with localized shell objects, it shows their real name on disk. Cool admin stuff!

[WorBry]

It should, but as the screenshot shows, it didn't (or system restore messed up somehow)

If you mean the VCSwap screenshot, yes that was at the start when FFDShow was installed. Following umezawa_takeshi's post I uninstalled it, and found it didn't resolve anything.

After your last post about locating and deleting the ff_vfw.dll's and registry keys, I installed FFDshow again to see what you were referring to. A regular Windows Explorer search turned up just one ff_vfw.dll in the C:\Windows\ SysWOW64 folder. Didn't take any direct action on that being unable to locate the other ff_vfw.dll.

But on uninstalling FFDShow again the ff_vfw.dll in the C:\Windows\ SysWOW64 folder disappeared, as might be expected. Hence my asking whether uninstalling was not just doing the same thing. As of now FFDShow is uninstalled.

So, would you suggest I go at it again looking for any registry keys that could still be there? Un-ventured territory for me, this registry stuff.

[qyot27]

Just use CCleaner to scrub the registry; repeat until you don't get any results back.

[WorBry]

Thanks. Just tried that. With FFDShow already uninstalled, I then uninstalled UTVideo 15.4.0, rebooted and ran CCleaner's registry cleaner three times (rebooting between each clean). Reinstalled UTVideo 15.4.0. Still no RGB FourCC's.

[Ignus2]

The problem is the way VFW works. The codec DLL given for a given fourcc in the registry is not authoritative. VFW will probe every codec sometimes for a given fourcc and the first to respond wins. As the description and short name didn't appear in VCSwap I was assuming the codec initialization failed, and as Takeshi examined, the UT DLL was not loaded at all, so something else responded, and I assumed it was the FFVFW variant as it also handles UT codecs.
At least, that's my assumption.

Can you post a new screenshot of VSwap?

Greets,
I.

[umezawa_takeshi]

I install ffdshow and UtVideo in test VMs in preceding order and reversed order, but VCswap shows that all of FourCC is still available in both case. My hypothesis may be rejected, or there are more conditions. hmm...

I sometimes hear that all of FourCC in UtVideo is not available, but I have never heard that some of FourCC in UtVideo is not available...

The problem is the way VFW works. The codec DLL given for a given fourcc in the registry is not authoritative. VFW will probe every codec sometimes for a given fourcc and the first to respond wins

Is that so? I didn't know that.

[raffriff42]

It's kinda that way, according to Avery Lee:One video codec to break everything (http://www.virtualdub.org/blog/pivot/entry.php?id=139)

The way that video codecs work in Windows is that each one is queried in turn and asked if it supports the compressed video format. If a codec says "yes," then that codec is used to decode the video. Otherwise, Windows proceeds to the next video codec down the line, until it either finds one that can handle the format or runs out of video codecs. The details are different between Video for Windows and DirectShow, but the general idea is the same. This provides a great deal of flexibility, because a video codec can decode more than one format. Some MPEG-4 video codecs, for instance, can helpfully also decode uncompressed YCbCr formats that are difficult to find dedicated codecs for, like YV12.

It also adds a bit of fragility, in that occasionally a video codec's decompression query routine acts as follows:

Q: Do you support video format....
A: Yes!
Q: Uh, I didn't tell you the video format. You really support this?
A: Yes!

The errant video codec then proceeds to capture every video format that comes its way, and happily barfs whenever it gets any format other than the one it was supposed to handle...

[LigH]

I remember from old Windows versions that it was possible to change the order of VfW codecs (not as detailed as DirectShow merits, but at least at all). But I am afraid that you may not find access to this dialog easily since Vista. It was contained in simple dialogs like you may know from the device manager; VfW codecs used to be handled like devices once.

[shekh]

Another thing to try, delete ALL entries from these registry keys:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32

And then import utvideo.reg or reinstall utvideo.

The idea behind this: what if codec enumeration fails because of some other broken codec entry.

[LigH]

Another thing to try, delete ALL entries from these registry keys:

:eek: Insanity level is OVER 9000!!! :confused:

That will probably destroy the whole legacy multimedia system. Even deleting "all VIDC.* entries" would possibly be overkill.

[WorBry]

Can you post a new screenshot of VSwap?


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

Just use CCleaner to scrub the registry; repeat until you don't get any results back.

Thanks. Just tried that. With FFDShow already uninstalled, I then uninstalled UTVideo 15.4.0, rebooted and ran CCleaner's registry cleaner three times (rebooting between each clean). Reinstalled UTVideo 15.4.0. Still no RGB FourCC's.

And I assure you that no ff_wfw.dll was not listed there in VCSwap at that point.

:eek: Insanity level is OVER 9000!!! :confused:

That will probably destroy the whole legacy multimedia system. Even deleting "all VIDC.* entries" would possibly be overkill.

So maybe not a good idea to try that then?

[shekh]

So maybe not a good idea to try that then?

You dont lose anything.

My algorithm would be:
go to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32
Rename Drivers32 to Drivers32~ (for use as backup)
Make fresh Drivers32 key
make string value vidc.ulra = C:\Windows\system32\utv_vcm.dll
open 32bit VD and see it codec is listed

yes: move other keys from Drivers32~ key to Drivers32 one by one

no: roll back all changes by renaming Drivers32~ to Drivers32

IMO there is no need to restart system at any point.

[sargan]

People old enough to remember the "Norton Commander" (but not excluding younger people) may also like the Far manager (http://www.farmanager.com), which is also available in 32 and 64 bit. It is a real text mode application, adapting to any arbitrary console window size. There are several plugins available, e.g. a Registry browser too. And it doesn't camouflage system directories with localized shell objects, it shows their real name on disk. Cool admin stuff!

Used to love Norton Commander - great interface at the time

[WorBry]

I'm just watching how things progress with:

http://forum.doom9.org/showthread.php?p=1756489#post1756489

[Q-the-STORM]

Is there a way to use UtVideo Pro YUV422 10bit in Premiere Pro CC 2015?
I'd like to export to UtVideo Pro YUV422 10bit and then encode with x264, but in Premiere only RGB, RGBA, 420 bt601, 420 bt709, 422 bt601 and 422 bt709 are available...

[umezawa_takeshi]

Is there a way to use UtVideo Pro YUV422 10bit in Premiere Pro CC 2015?

Practically, NO. "UtVideo Pro YUV422 10bit" (UQY2) is almost useless at the moment.

In addition, x264 probably does not accept UQY2 (because libavcodec does not support it, either).

[WorBry]

Thanks for all of your responses. I haven't tried shekh's suggestion as yet....

You dont lose anything.
My algorithm would be:
go to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32
Rename Drivers32 to Drivers32~ (for use as backup)
Make fresh Drivers32 key
make string value vidc.ulra = C:\Windows\system32\utv_vcm.dll
open 32bit VD and see it codec is listed

yes: move other keys from Drivers32~ key to Drivers32 one by one

no: roll back all changes by renaming Drivers32~ to Drivers32

IMO there is no need to restart system at any point.

and I will at some point; that said, I'm not exactly sure about the step "Make fresh Drivers32 key". How do I do that?

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

I have another question though about transcoding full scale (0-255) YV12 sources to UTVideo with FFMPEG. As mentioned in an earlier post:

http://forum.doom9.org/showpost.php?p=1755029&postcount=434

When transcoding native AVC HD clips (mov or mp4) from DSLR cameras recorded with full range (0-255) YV12 luma to UTVideo (YV12 or YUY2), the yuvj420p and yuvj422p pix_format designations are not accepted and FFMPEG reverts to yuv420p and yuv422p resulting in compression to limited 16-235 scaling. Same occurs with other lossless/near-lossless formats like HuffYuv, FFV1, ProRes, DNxHD e.g

ffmpeg -i path..../DSCN0968.MOV -vcodec utvideo -r 30000/1001 -pix_fmt yuvj420p -s 1920x1080 path...../DSCN0968_UTVYV12_Fullscale.mkv

ffmpeg log gives:

Incompatible pixel format 'yuvj420p' for codec 'utvideo', auto-selecting format 'yuv420p'
[swscaler @ 0x7d08e0] deprecated pixel format used, make sure you did set range correctly


In my tests the only two formats where the yuvj420p and yuvj422p pix_format are respected are uncompressed rawvideo (YV12, YUY2) and x264. Interestingly, when these transcodes are loaded into KdenLive and Clip Properties (metadata) are examined, they are reported as having yuv420p or yuv422p pix_format's despite being full scale. Whereas the original camera clips display the yuvj420p and yuvj422p pix_formats.

It occurred to me then that if I use the rawvideo transcodes as input for FFMPEG encoding to UTVideo it might be possible to preserve (pass-through) the full range scaling. Tried that and lo and behold that is the outcome, e.g.

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

then

ffmpeg -i path...../DSCN0968_RawYV12_Fullscale.mkv -vcodec utvideo -r 30000/1001 -s 1920x1080 path /DSCN0968_UTVYV12_Fullscale.mkv

So there is at least a way to transcode the native clips to UTVideo and preserve the full scale luma, at the cost of generating very large uncompressed intermediates.

My question is – is it possible to set up a single FFMPEG command that avoids this two stage process ? I'm afraid I don't have any experience with FFMPEG piping (other than basic piping out from VapourSynth with vspipe). My several attempts always result in FFMPEG crashing due to memory allocation problems.

Edit: sorry about the text formatting. I had to draft the post offline and it got messed up.

[richardpl]

Yes there is a way, use something like this:

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

[WorBry]

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

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

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

Over my head at this point.

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

i.e. the equivalent of

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

and then:

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

[WorBry]

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

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

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

Over my head at this point.


OK, based on this VapourSynth ShufflePlanes filter documentation:

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

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

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

and

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

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


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

i.e. the equivalent of

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

and then:

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

[richardpl]

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

[WorBry]

Oh, hang on, some needless complication there:



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

and

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



No need to do the shuffle planes thing in VapourSynth:

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

and for YUY2:

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

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

[zerowalker]

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

[umezawa_takeshi]

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

New features

Windows: Priority of worker threads can be now modified.

Bug fixes

VCM codecs suggested output formats for some unsupported input formats.


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

[Sparktank]

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

Thanks for the updates.:goodpost:

[WorBry]

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

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

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

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

[roman]

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

[filler56789]

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

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

[Taurus]

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

[Ignus2]

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


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

Greets,
I.

[roman]

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

[roman]

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

[WorBry]

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


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

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

Like I said:


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

[umezawa_takeshi]

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

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

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

[Taurus]

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

[raffriff42]

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

[umezawa_takeshi]

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

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

Then the first post is out of date...

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

Redist is not required since UtVideo 6.0.1.

[roman]

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

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

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

[roman]

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

[foxyshadis]

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



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

Redist is not required since UtVideo 6.0.1.

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

[Emulgator]

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

[umezawa_takeshi]

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

Thank you.

[umezawa_takeshi]

Hello, all.

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

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

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

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

[kolak]

Great news!

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

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

It should be stored in:

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

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

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

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

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

[umezawa_takeshi]

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


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


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


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

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



Edit xml...


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

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

What differences are there...

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

[kolak]

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

What about vendor? Do you use anything specific?


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

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

together with many others.

DPX pixel format is here:

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

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

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

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

or

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

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


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

[umezawa_takeshi]

What about vendor? Do you use anything specific?


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


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


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

[kolak]

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

[umezawa_takeshi]

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

[kolak]

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

[umezawa_takeshi]

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

New features

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

Bug fixes

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


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

[shekh]

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

[kolak]

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

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

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

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

Test done in latest Edius 8.2.

[umezawa_takeshi]

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

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

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

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

[Ignus2]

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

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

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

Greets,
I.

[kolak]

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

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



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

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

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

[umezawa_takeshi]

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

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

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

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

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

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

---

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

[kolak]

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

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

[poisondeathray]

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

[GMJCZP]

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

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

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

[kolak]

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

[GMJCZP]

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

[Groucho2004]

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

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

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

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

[GMJCZP]

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

[Rush_iam]

Why I get wrong colors?

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

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

Can anybody help? Thanks!

[LigH]

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

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

[Rush_iam]

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

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

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

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

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

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

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

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

[LigH]

Did you use any of the following x264 parameters when converting from the Ut 709 material?

--colorprim <string> Specify color primaries ["undef"]
- undef, bt709, bt470m, bt470bg, smpte170m,
smpte240m, film, bt2020
--transfer <string> Specify transfer characteristics ["undef"]
- undef, bt709, bt470m, bt470bg, smpte170m,
smpte240m, linear, log100, log316,
iec61966-2-4, bt1361e, iec61966-2-1,
bt2020-10, bt2020-12
--colormatrix <string> Specify color matrix setting ["???"]
- undef, bt709, fcc, bt470bg, smpte170m,
smpte240m, GBR, YCgCo, bt2020nc, bt2020c

[Rush_iam]

Yes, I used all of them. Players seems to ignore that or already interpets it as BT.709 and it look like wrong conversion occured before H.264 encoding.
As I pointed out before - even source .AVI Ut BT.709 plays wrong in WMP, wrong in AviSynth and wrong in HandBrake (and correctly in VDub).

[shekh]

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


Since you already confirm that it works correctly at least in VDub there cannot be bug in codec.

Decoder can output RGB or YUV, if players do request YUV they have all the chances to get it wrong.

Btw, why do you compare "warmth" of colors when you can compare colors themselves. Take this: https://drive.google.com/open?id=0B8BT09xR2LmaMGdiNTM4RHVMLTg

[umezawa_takeshi]

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

New features

QuickTime version are now compatible with Adobe software.


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

[kolak]

Seams to be working now (tested Mac version).

[foxyshadis]

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

Unfortunately, if a player's broken it's just broken. I'd imagine most players/renderers ignore the metadata and either switch based on >540p, or just have one hard-coded YUV matrix. You can't fix that in a codec. Browser-based players and WMP are notoriously bad, because they know that 99% of their audience doesn't care, so they don't have to either.

[Bloax]

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

Anyway, it seems that the move to VS2015 and the XP compatibility switches are the reason it won't work on XP.
Microsoft suddenly introduced this "feature" to MSVC2012 after XP reached the end of its life.
Not sure what's up with it stopping again and then popping up again with MSVC2015.

You can judge for yourself what the purpose of that was. :^)
A little chitchat was had about that here (http://encode.ru/threads/1838-Command-Line-Process-Profiling-Tool?p=35651&viewfull=1#post35651), and there's even a little tool for fixing that little "omfg invalid win32 program" feature (MakeLX -> MakeXP) (http://encode.ru/threads/1838-Command-Line-Process-Profiling-Tool?p=35716&viewfull=1#post35716)

[GMJCZP]

groucho, bloax:
I can install the latest version but obviating utv_dmo.dll registration. I can use the program but do not know what the impact of omitting the registration.
The program MakeXP is like swiss file knife (sfk)?

[FranceBB]

@GMJCZP... I modified the .vcxproj files in order to target XP and make ut video xp compatible.
Despite the fact that it allowed me to launch the build after editing these files (ToolsVersion=10.0 and <PlatformToolset>v100</PlatformToolset>), it failed while building it. I assume that Umezawa used something that isn't compatible with the MSBuild provided with Visual Studio 2010. I tried to compile it with mono using "xbuild", but it failed as well.

http://ft.trillian.im/60370e90cb2f6ffd369eaa0d0caa4632c7d3dd08/6Hmpti7cmwkgFoCFNU5NdISSmlTix.jpg

[foxyshadis]

inttypes.h is C99, which was first fully supported in VC2013 -- if you can't work with a C99 compiler, you're on your own. atlbase.h is part of VS Professional, unfortunately, not Express Edition.

You can "find" these headers online, but realistically, you should move your build environment ahead (even if it's a virtual machine), because things will only get more difficult. I really don't understand holding on to XP, but it's still possible to build for it, even if the build tools no longer install on it.

[FranceBB]

@foxyshadis... I see... Anyway, I actually run my encoding in a machine running Windows Server 2008 R2 at work and Windows 7 Professional at home (licence provided by the company itself) but it would have been nice to have something backward compatible with XP 'cause a lot of people are still using XP and/or Win server 2003.

Anyway, thank you for the explanation ^_^

p.s no luck with MinGW (GCC C++) as well :(

http://ft.trillian.im/60370e90cb2f6ffd369eaa0d0caa4632c7d3dd08/6Hpc4jVtg2DUhzsLfRxJxDsbnrysC.png

[Ignus2]

As a side note, if the codec uses Windows APIs introduced with Vista, you would also have to re-implement those too in some other ways, otherwise the binary will fail on XP at runtime.

Greets,
I.

[mp3dom]

I'm always getting an out-of-bounds error (and then the crash) in VDub using ULH2 with Predict left AND assume interlace video flag on. The encoding process doesn't even start (the filesize is fixed at 0 bytes).
15.2.0 works as expected, but higher version (tried 15.5 and 16.x) fails.

[umezawa_takeshi]

I confirmed that encoder crashes if "assume interlace video" option is checked. (probably since 15.4.0)

Decoding "assume interlace video"-enabled video does not seem to be broken.

[filler56789]

Hmmm, the latest version of the DMO decoder makes regsvr32 crash. Version 15.5.0 still works OK.

[dipje]

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

How do you get something b64a into vdub in the first place? :).

I've got some Vapoursynth scripts that output in RGB30 or RGB48, but I still can't get a way to pipe that straight into Utvideo.

Best way for me now seems to go Vapoursynth RGB30 -> ffmpeg dpx sequence -> Adobe AE render sequence as utvideo RGB-10bit (UQRG).

Was hoping VdubFilterMod had native .vpy support but it still goes through the VfW interface it seems, limiting it to v210 as the highest deep color format (Vapoursynth's VfW interface has no RGB30/RGB48 from what I can tell).

Vapoursynth directly into ffmpeg is no problem, but ffmpeg doesn't encode to UQRG/UQRA/UQR2 :(.

[shekh]

How do you get something b64a into vdub in the first place? :).

I've got some Vapoursynth scripts that output in RGB30 or RGB48, but I still can't get a way to pipe that straight into Utvideo.

Best way for me now seems to go Vapoursynth RGB30 -> ffmpeg dpx sequence -> Adobe AE render sequence as utvideo RGB-10bit (UQRG).

Was hoping VdubFilterMod had native .vpy support but it still goes through the VfW interface it seems, limiting it to v210 as the highest deep color format (Vapoursynth's VfW interface has no RGB30/RGB48 from what I can tell).

Vapoursynth directly into ffmpeg is no problem, but ffmpeg doesn't encode to UQRG/UQRA/UQR2 :(.

A while ago I asked if VS would support b64a output via vfw, but nobody was interested and supporting native interface was beyond my reach.
If you can create dpx sequence VirtualDub can open it too, as well as any other ffmpeg output.

[dipje]

I believe (but don't quote me on that :P) that myrsloik said something like 'show me a program that can actually do something useful with it and it would be trivial'. To be honest, I don't know if the topic was about b64a, but at least about something 'higher and more than v210' so to speak :).

With UTVideo now having 10bit-RGB and RGBA versions, and those versions actually working (well) in Adobe After Effects would maybe be a trigger :).

To me it's basically a replacement for intermediate DPX sequences when working with camera captures from yuv444p10 prores files. Specially when working on a laptop on the go, utvideo requiring about 50% of the storage space helps a lot in how fast you can scrub through a video clip in Adobe AE :).

I'm happy with either RGB30 / RGB48 DPX sequences if I want absolutely lossless, prores 4444 as 'visually lossless' alternative. All work from vpy -> ffmpeg -> AdobeAE.

[shekh]

I hardly follow where is the problem to solve. If you want to connect Vapoursynth with Virtualdub, maybe ask it in Vapoursynth thread.
But if you want to convert prores to UTVideo with Virtualdub, I think it can do.

[dipje]

It's no biggie.

I _would_ want to go from vapoursynth RGB48 / RGB30 directly into utvideo UQRG, and the only thing preventing it is that either vapoursynth didn't implement something yet (I go and ask in their thread :)) or ffmpeg isn't up2date enough with utvideo-encoding yet.

Frustrating, that's all :).

[umezawa_takeshi]

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

Bug fixes

Encoders crash if "Assume interlace video" option is enabled.

Others

Removed QuickTime for Windows codec.


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

[GMJCZP]

Takeshi, this build it works (apparently) in XP SP3 but obtain the same error as in post # 503.

[umezawa_takeshi]

Support of Windows XP is dropped since version 14.0.0.

[dipje]

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

Others

Removed QuickTime for Windows codec.



So I guess people stay at 16.1.0?

[umezawa_takeshi]

Yes.

note: you can build it by yourself.

[Selur]

Is there a way do distinguish whether a ULH0 is pc or tv range, since medainfo always reports for both bt.709 (which in contrast to rec.709) should be tv range.

[De-M-oN]

Why is there no YUV 4:4:4 Encoder? :-(

[umezawa_takeshi]

Is there a way do distinguish whether a ULH0 is pc or tv range, since medainfo always reports for both bt.709 (which in contrast to rec.709) should be tv range.

I don't understand what you ask...

When ULH0 (and ULH2, ULY0 and ULY2) converts YUV from/to RGB, YUV is assumed TV scale (limited range) and RGB is assumed PC scale (full range). There is no option to change this behavior.

Why is there no YUV 4:4:4 Encoder? :-(

Because I don't need it and no one has ever requested me to implement it.

[Sparktank]

Removed QuickTime for Windows codec.


So I guess people stay at 16.1.0?

What is the advantage of using QT for Windows?
What is the typical case scenario where I would want to use 16.1.0 over future uses?

I'm currently using the 16.1.1 release.

[De-M-oN]

YUV 4:4:4 would be very helpful for game capturing.

I dont need RGB for capturing, while YUV 4:4:4 would offer the same quality (the final lossy coded video would be TV Range anyway).
So with YUV 4:4:4 you still have full chroma, but with an insane reduction of filesize and system ressources. On the game rise of the triad the HDD RAID 0 was overloaded with RGB @ 2560x1600, 50fps while YUV 4:4:4 worked perfectly fine.

At the moment I use MagicYUV, but I think that people who use UTVideo should have the possibility to have 4:4:4 chroma as well. And if the codec is similar fast as MagicYUV, maybe even I would try it out, because AmarecTV 3.10 for some reason does close the avi file with some index entry errors in seldom cases. And then MagicYUV is not that spreaded into every software. I could imagine that UTVideo has maybe easier times to be repaired so far (less loss of frames - my last capture lost 3min, I could reduce it to 27 seconds lost, by using several software, but still a loss. And I dont get why these index entry errors happen sometimes at amarec. Maybe amarec sometimes dislike magicyuv? - or amarec itself is buggy in that manner? - I dont know. I just know, that I sometimes in seldom cases have to rebuild the index, and it will be hard to reproduce for a developer if a thing happens just seldom :S

[umezawa_takeshi]

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

New features

Added codecs whose internal formats are YUV444 8bit (FourCC: ULY4, ULH4). Not very fast in case of RGB input/output.


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

[De-M-oN]

awesome!! ♥

Not very fast in case of RGB input

What do you mean by that? Is it slower than MagicYUV's YUV 4:4:4?

On MagicYUV it is for me a lot faster at YUV 4:4:4 compared to RGB, due to datarates to my storage.

[shekh]

He said don`t send RGB to YUV codec :)

[De-M-oN]

Capturing computer games (be it my datapath capture card or for other people a gameengine hook program) results always into an RGB32 input though :p

[umezawa_takeshi]

RGB <-> YUV444 conversion is not optimized.

Some users who do not need speed can accept benefit of YUV444 by this version. If you need speed, wait later version. No problem.

[De-M-oN]

Okay. Thanks for clearing up.

Then I'm looking forward for this and so far: Thank you so much ♥

[Sparktank]

What is the advantage of using QT

Anyone can answer this.

Some users switched to older versions to use QT.

[LigH]

Possibly the only advantage could be to use also the QuickTime Player Pro or other QuickTime supporting media editors to store and play MOV files with Ut video streams (means: a bit more market coverage). But you could probably use ffmpeg supporting tools as well. There is no real advantage in using the MOV container for wrapping Ut video streams in it, other containers are just as useful.

[umezawa_takeshi]

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

Performance Improvements

ULY4,ULH4: Speed up encoding from RGB formats.
ULY4,ULH4: Speed up decoding to RGB formats.


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

In addition, minimum supported OS (Mac) is now 10.10 Yosemite.

[dipje]

Qt encoders and decoders made it possible to use it video in tools like after effects and premiere with 10bit deep color.
Putting it into an Avi container breaks this because the Adobe software doesn't really support vfw / directshow decoders with deep color .

To be honest, this was my testing back then. Ut in mov was reported as trillions of colors, ut in Avi was reported as millions.

Thing is,since then I noticed after effects can open b64a Avi files but also reports them as just millions of colors. But testing with gradients and looking for artifacts and banding it seems something of precision actually comes across.

So what I'm saying is, I only saw ut in Avi being reported as as millions and _thought_ that means no 10bit.
Now I'm actually not sure,need to test again. Maybe Adobe made some changes without listing them in the release notes.

Still, not having the encoders means no deep color output from the Adobe suite, which is a shame since he just implemented it.

No updates for the quicktime player doesn't mean the codecs are immediately an issue. That's like saying windows media player is insecure and unsupported, so you stop making directshow filters. Not always the same thing.

So apple stopping support for the quicktime player under windows does not mean you have to stop support for quicktime codecs in my book.

But I'm not the utvideo developer, and he can make his own choices (and may have reasons I don't know about ). I'm perfectly happy with what I have and how awesome it is we have things like utvideo for free.
And I'm perfectly happy using an older version which supports what I like.

[Taurus]

Version 17.1.0 (http://umezawa.dyndns.info/wordpress/?p=6107) is released.
:thanks:Thank you for this wonderful encoder suite.
I'm using it for years now and it's getting better all the time.
Really appreciated.:thanks:

[umezawa_takeshi]

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

Performance Improvements

Speed up decoding significantly.


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

[GMJCZP]

Thank you!

[Taurus]

Thank you!
And a Happy New Year!

[umezawa_takeshi]

I took small benchmarking of three latest codecs (UtVideo, MagicYUV and AMV4) and one classic codec (Lagarith).

http://umezawa.dyndns.info/wordpress/?p=6229 (English)
http://umezawa.dyndns.info/wordpress/?p=6203 (Japanese)

[Ignus2]

I took small benchmarking of three latest codecs (UtVideo, MagicYUV and AMV4) and one classic codec (Lagarith).

http://umezawa.dyndns.info/wordpress/?p=6229 (English)
http://umezawa.dyndns.info/wordpress/?p=6203 (Japanese)

Nice article.
Could you run the benchmark with the original 4k material?
With 2k coding approaching the 1000s in FPS in some cases, it is no longer a challenge (the codecs don't really have a chance to warm up and time is beginning to be wasted on multi-core sync rather than actual work).

EDIT: It's nitpicking, but the compression ratio chart doesn't start at zero (it is truncated at 1.0).

Greets,
I.

[umezawa_takeshi]

Could you run the benchmark with the original 4k material?
With 2k coding approaching the 1000s in FPS in some cases, it is no longer a challenge (the codecs don't really have a chance to warm up and time is beginning to be wasted on multi-core sync rather than actual work).

Yes, that's right. However, I didn't have suitable 4K clips, so I bechmarked with 2K clips reluctantly.

I want to benchmark with 4K (or more) clips at the next time.

It's nitpicking, but the compression ratio chart doesn't start at zero (it is truncated at 1.0).

Ratio = 1.0 means "could not compressed at all" and compression whose ratio less than (or equals to) 1.0 is absolutely meaningless. That is why I decided that the chart starts at 1.0.

[Ignus2]

Yes, that's right. However, I didn't have suitable 4K clips, so I bechmarked with 2K clips reluctantly.

The one you used, in 2160p: https://media.xiph.org/video/derf/y4m/crowd_run_2160p50.y4m

Ratio = 1.0 means "could not compressed at all" and compression whose ratio less than (or equals to) 1.0 is absolutely meaningless. That is why I decided that the chart starts at 1.0.

I left my brain in my pocket when I made that remark, sorry :)

Greets,
I.

[umezawa_takeshi]

The one you used, in 2160p: https://media.xiph.org/video/derf/y4m/crowd_run_2160p50.y4m

No. That has a problem.

If the file (YUV420) is converted to other pixel formats (RGB444, YUV422, etc), the resulting clip has lower entropy. This leads higher compression ratio than that should be. Similarly, encoding/decoding speed may or may not be affected. We need RGB444 or YUV444 clips (with appropriate entropy).

(Of course, using the clip to benchmark YUV420<->ULY0/M8Y0 process is OK)

[Ignus2]

Then some of the 4k TIFFs of the Tears Of Steel open movie: https://media.xiph.org/tearsofsteel/tearsofsteel-4k-tiff/
Though smaller than UHD (4096x1714 vs 3840x2160), it's better than nothing.

Greets,
I.

[umezawa_takeshi]

Great!

[Ignus2]

I also wrote an article about benchmarking, here: https://www.magicyuv.com/articles/video-codec-benchmarking-done-right/
The tool I wrote is more crude than yours (it can only read raw and a primitive compressed raw format, not AVIs), but there are some things that you might find useful there (CPU freq locking and why is that important, conversion of the tiffs with ffmpeg, etc.).

Greets,
I.

[kolak]

ffmpeg.exe -i frame%05d.tif -pix_fmt bgr24 -f rawvideo -vf scale=3840:2160 4k_bgr24.raw

add -start_number before -i and then your image sequence doesn't need to start with 0, eg.

ffmpeg.exe -start_number 123 -i frame%05d.tif -pix_fmt bgr24 -f rawvideo -vf scale=3840:2160 4k_bgr24.raw

Numbers have to be sequential though.


With -pattern_type glob they don't need to be sequential, eg.

ffmpeg.exe -pattern_type glob -r 25 -i '*.tif' -pix_fmt bgr24 -f rawvideo -vf scale=3840:2160 4k_bgr24.raw

[Ignus2]

ffmpeg.exe -pattern_type glob -r 25 -i '*.tif' -pix_fmt bgr24 -f rawvideo -vf scale=3840:2160 4k_bgr24.raw

Try it on Windows and you'll see why I didn't use it :)
ffmpeg on Windows (at least zeranoe) doesn't support globbing. Also confirmed here: https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2176

So you have to be sequential. Which means you have to rename anyway, so just rename from zero and you'll won't need start_number either.

I considered these options :)

Greets,
I.

[kolak]

I'm sure I used it, but maybe it was always on Mac? Not 100% sure :)
What if also you add -f image2 in-front of -i ?

[Ignus2]

Well, I'm 100% sure it wasn't on Windows :)
-f image2: same thing, believe me, I tried all possibilities :)

[umezawa_takeshi]

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

New features

ULY2, ULH2, ULY0, ULH0: Add support of input from / output to YV16.

Performance Improvements

ULY4, ULH4, ULY2, ULH2, ULY0, ULH0: Speed up input from / output to native planar formats.


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

[EuropeanMan]

Sorry sir, I'm new to this codec.
I've been using lagarith for ages and ages. I've never had a problem. Just today, I was browsing around and saw this, and I'm impressed with the charts you've shown on your blog. Thank you for your efforts.

I'm going to be lazy here & not search throughout this entire thread, but I'll explain what I do with my DVDBackups.

If I'm unhappy with a DVD I buy, I put it on my computer, then fix the problems in AviSynth (AVS file)...run it through either Vdub or MeGUI...but first I load my script into Vdub, and select Lagarith compression and then let it run my encode...from that lag file, I then compress the file using another AVS script into CCE/Xtream to make my m2v file, etc etc.

With your codec that I just installed, which UtVideo should I be using in the menu for compression? Thanks in advance. CCE/Xtream takes Yuy2 video as far as I remember. I'm assuming the Lag file is always sent into Yuy2. I'm a n00b when it comes to these codecs...sorry

[LigH]

MPEG2 video on DVD is based on YUV video with chroma subsampling 4:2:0, the most similar FourCC supported in AviSynth is 'YV12'. Furthermore, SD resolutions are usually provided with a colorimetry like ITU-R BT.601 (except you would see a different one in the analysis window of DGIndex from DGMPGDec). The most similar Ut codec would therefore most probably be "UtVideo YUV420 BT.601 VCM" (FourCC: 'uly0').

Another great DVD Video compliant and free MPEG2 encoder which accepts YV12 video via AviSynth script is the HC encoder.

[EuropeanMan]

^ thank you LigH. I have Hcenc. Personally I feel CCE far outshines Hc.

[kolak]

Yep, specially for progressive sources. YUY2 is what you want to feed into CCE.

[osgZach]

I think I have found a bug.

under 17.3.0 ULH0 appears to be decoded as YV16 instead of YV12. I rendered output from Magix Vegas Pro 14 using YUV420 BT.709 VCM and was surprised when MeGUI warned me the video was not YV12.
reinstalling 17.2.0 resolved the issue.

My OS is
Windows 10 Professional x64
Avisynth 2.60 x32

The video was loaded via AviSource()

[umezawa_takeshi]

It is AviSynth's problem.

AVISource just tries output formats in the filter’s predefined order, regardless of codec's most preferred output format. AVISource tries YV16 before YV12, so YV16 is chosen in the case of UtVideo 17.3.0. See http://avisynth.nl/index.php/AviSource for more information.

If you want specific output format, You should always specify pixel_type.

[osgZach]

Thank you for this information.

[umezawa_takeshi]

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

Performance Improvements

UQY2, UQRG, UQRA: Speed up encoding.


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

[djonline]

I took small benchmarking of three latest codecs (UtVideo, MagicYUV and AMV4) and one classic codec (Lagarith).

http://umezawa.dyndns.info/wordpress/?p=6229 (English)
http://umezawa.dyndns.info/wordpress/?p=6203 (Japanese)

Can you add FFV v1 and v3 to this comparision ?
FFV1 can be used to upload lossless exported video to Youtube, without any unnecessary recompress.
But there is no FFV1v3 VFW encoder still :( FFdshow from 2014 has only FFV1 v1.

Why UT Video is so slow in RGB->420, unlike MagicYUV ? May be this was fixed in 17.4.0 ?

[kolak]

FFV1 is slow. It's about compression not speed.

[umezawa_takeshi]

Can you add FFV v1 and v3 to this comparision ?
FFV1 can be used to upload lossless exported video to Youtube, without any unnecessary recompress.
But there is no FFV1v3 VFW encoder still :( FFdshow from 2014 has only FFV1 v1.

OK. I will add FFV1(v1) next time (probably this summer). It may be removed at the time after the next, however, because ffdshow is inactive for a long time. The benchmarking tool I use only support VCM(VfW) interface, so I have to use ffdshow, not directly FFmpeg.

Why UT Video is so slow in RGB->420, unlike MagicYUV ? May be this was fixed in 17.4.0 ?

Because RGB<->YUV420 conversion is not optimized at all (written in C and uses fp calculation!). It's same in 17.4.0.

[umezawa_takeshi]

FFV1 is slow. It's about compression not speed.

Come to think of it, that's right. hmm...

[umezawa_takeshi]

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

New Features

ULxx: Add "Predict Gradient" intra-frame prediction method.

Performance Improvements

ULxx: Speed up encoding.


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

In most cases, "Predict Gradient" achieves better compression ratio, encoding speed and decoding speed than "Predict Left". See comparison in my blog's post.

[olif]

Hi,

my problem is, when I try to record Arma 3 I have to use the 32 bit version of UTVideo, because when I want to use 64 bit, it does not happen more than "Init".

Anyone is able to confirm this problem?

Best regards

[umezawa_takeshi]

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

Performance Improvements

ULY0, ULH0: Speed up input from / output to RGB formats and YV16.

Bug fixes

ULY4, ULH4, ULY2, ULH2: QuickTime component sets wrong alpha value while decoding to ARGB.


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

[easy2Bcheesy]

@umezawa_takeshi

Would you ever consider developing a high performance, lossy VFW codec? An open source ProRes alternative, perhaps?

4K 60Hz game capture cards are starting to appear, and even 4:2:0 UT files are 150MB/s to 450MB/s. To the best of my knowledge, there is no efficient, ProRes style VFW codec available that is fast enough. The best would be CineForm, but only the DirectShow version is fast enough and that's not compatible with most capture tools.

[De-M-oN]

Use OBS Studio (with your card) combined with NVEnc for the encoding.
near no FPS loss and you decide if lossless or lossy ;)

[mariush]

Someone needs to make a hardware chip that implements that DSC visually lossless real time compression which reduces the bitrate by up to 3 times. Then simply push the bitstream through usb 5gbps or 10 gbps (usb 3.1) to the computer.

See http://www.vesa.org/wp-content/uploads/2014/04/VESA_DSC-ETP200.pdf

and see VESA DSC 1.1 Encoder IP Core (on xilinx fpga) : https://www.xilinx.com/products/intellectual-property/1-8effft.html

Or you know, maybe we just have to wait for 16 core / 32 thread threadripper and have each core encode 2 frames in real time using 7z

[umezawa_takeshi]

I have no plan to develop lossy codec because:

It is difficult. Compared to lossless codecs, lossy codecs have additional important characteristic --- image quality. It is difficult to evaluate image quality, and it is difficult to find good balance with other characteristics.
There should be already good ones, shouldn't there?
I don't need lossy codecs like ProRes (i.e. visually lossless and fast enough to be used to video capture).

[kolak]

Someone needs to make a hardware chip that implements that DSC visually lossless real time compression which reduces the bitrate by up to 3 times. Then simply push the bitstream through usb 5gbps or 10 gbps (usb 3.1) to the computer.

See http://www.vesa.org/wp-content/uploads/2014/04/VESA_DSC-ETP200.pdf

and see VESA DSC 1.1 Encoder IP Core (on xilinx fpga) : https://www.xilinx.com/products/intellectual-property/1-8effft.html

Or you know, maybe we just have to wait for 16 core / 32 thread threadripper and have each core encode 2 frames in real time using 7z

Problem is that you can't guarantee and don't know lossless compression ratio on given footage. Some footage will compresses only 1.5x times, other 4x, so this is big problem. You would have to have fallback lossy mode with some fixed eg. 3x compression. You can also forget about lossless mode and design 3:1 lossy codec which would be good enough quality anyway. Such a solutions are coming as broadcast industry is switching to video over IP. There are already new cards which can send uncompressed or JPEG2000 over IP. More codecs will come.

[nevcairiel]

Problem is that you can't guarantee and don't know lossless compression ratio on given footage. Some footage will compresses only 1.5x times, other 4x, so this is big problem. You would have to have fallback lossy mode with some fixed eg. 3x compression. You can also forget about lossless mode and design 3:1 lossy codec which would be good enough quality anyway. Such a solutions are coming as broadcast industry is switching to video over IP. There are already new cards which can send uncompressed or JPEG2000 over IP. More codecs will come.

VESA DSC is a lossy encoder with a fixed compression ratio (although the ratio is variable and can be choosen to fit the available bandwidth, from 1:1 to 3:1).

[kolak]

Yes, because lossless mode is problematic when you have fixed bandwidth and need to guarantee compression ratio.
HDCAM-SR technology does switch between lossy and lossless mode when further ones fits into bandwidth limits. This is also some solution, though bit more complex.

3:1 can offer very close to lossless quality, so it's good compromise.

[easy2Bcheesy]

Use OBS Studio (with your card) combined with NVEnc for the encoding.
near no FPS loss and you decide if lossless or lossy ;)

Yes, I've tried that with a Magewell PCIe HDMI 2.0 capture card and a GTX 1080. At the risk of taking this thread OT, there are two issues here. To achieve ProRes-level quality, you need a CQP encode that produces files that are insanely difficult to decode in Adobe Premiere even on a 5820K. Meanwhile, ProRes 4:2:2 4K60 files playback in real-time on a Retina MacBook Pro! Secondly, OBS definitely drops frames more consistently than you would think and that's not an option for me - plus it seems to crash a lot.

I guess we live in a world where an Atomos Ninja Inferno is only a bit more expensive than an HDMI 2.0 capture card, but even so, I would love a PC solution.

I have no plan to develop lossy codec because:

It is difficult. Compared to lossless codecs, lossy codecs have additional important characteristic --- image quality. It is difficult to evaluate image quality, and it is difficult to find good balance with other characteristics.
There should be already good ones, shouldn't there?
I don't need lossy codecs like ProRes (i.e. visually lossless and fast enough to be used to video capture).


In the PC space, there really aren't any good lossy compressors except for the DirectShow-only CineForm. Certainly there are none that are fast enough to process 4K at 60 frames per second in real-time on reasonable PC hardware. Even UT 4:2:0 struggles on my 5820K for some reason (possibly bandwidth?). Even a IQ-selectable, super-fast MJPEG codec would probably do the job.

[easy2Bcheesy]

Yes, because lossless mode is problematic when you have fixed bandwidth and need to guarantee compression ratio.
HDCAM-SR technology does switch between lossy and lossless mode when further ones fits into bandwidth limits. This is also some solution, though bit more complex.

3:1 can offer very close to lossless quality, so it's good compromise.

UT 4:2:0 on 4K content from an 8-bit 4:2:2 input actually gets close to 3:1, 4:1 or better, depending on the content. Assuming 1GB/s coming from the capture card, I've seen some content encode at 150MB/s while the maximum I've seen is 450MB/s.

[kolak]

On "some source"- this is the problem. You can't guarantee it at all as generic rule.
Try to get 3 or 4:1 on assets straight from debayered RAW assets from camera, where all noise is still there etc. Good luck with 3:1 :) You quite often get 1.5:1, not even 2:1.
When you process sources (denoise, compress etc) then it encodes losslessly much better as files have way less "random information". On high quality assts directly from camera it's very difficult to go much above 2:1. 2:1 is sort of average, but you can't guarantee even 2:1 and this is the biggest problem. When you try to make some "system" with fixed restrictions bandwidth (e.g. send masters over IP with certain bandwidth) it has to work for all source, not just "some" :)
That's why fast and efficient 3:1 lossy mode is good compromise in my opinion.

[Tima]

I've captured a bunch of VHS tapes, and want to save TFF video (ULY2) and be able to play it back.

There's no field order option in the compression properties in VDub, and the video is treated as BFF during playback, leading to the jerky movement.

The only known workaround for me is to change video field order to BFF. It works, but is not convenient.

Is there a way to set field order for interlaced compression in UTVideo?
If not, that should definitely be a good feature request :)

[LigH]

Of course you should select the field order the video obviously has (testing the progress of the fields in a Bob check), if the video codec allows that.

The AVI container as such does not store a field order. 3rd-party tools like AviSynth cannot know whether a video codec does store a private flag regarding a field order or not, it can only assume that AVI files are BFF, because DV in AVI is BFF. How VirtualDub behaves, I am not sure... is there a lack of API to retrieve a field order from the codec? From MJPG codecs I remember that there was usually an explicit control in the codec setup.

[Tima]

Of course you should select the field order the video obviously has (testing the progress of the fields in a Bob check), if the video codec allows that.

Exactly.
My whole point is that there's apparently no way to set it for UTVideo.

[umezawa_takeshi]

Is there a way to set field order for interlaced compression in UTVideo?
If not, that should definitely be a good feature request :)

No, UtVideo does not care about whether the video is really interlace. It only has an option to achieve better compression if the video is interlace. (The phrase "assume interlace video" may be little confusing)

Raw video clips (like RGB24) themselves do not have interlace property. So UtVideo doesn't need it, too. I am not interesting in adding interlace property. I even think that I want to remove "assume interlace video" option.

[Tima]

Raw video clips (like RGB24) themselves do not have interlace property. So UtVideo doesn't need it, too.

Got the point and agree it's not essential for intra-only codec.

Probably I'll have to switch from AVI to another container where I can set field order (or just set it during the playback each time :)).

I am not interesting in adding interlace property. I even think that I want to remove "assume interlace video" option.

Please, don't remove it, as it greatly improves the compression!
(577->511 MB for one of my videos).

[LigH]

If you really have field-oriented video content (which looks "combed" when looked at as whole frames), then compression in "interlaced mode" (as separate fields) can indeed be more efficient. Even more so if you have a codec with temporal differencing (inter coding, at least "delta frames", or possibly "delta fields" in this case) and also the fields in the correct temporal order. Interlacing may be less common in times of HD videos. But as long as they still exist, treating them appropriately may give you an edge. For a good reason, MeGUI and ConvertXtoHD use quick interlaced compression with x264 to detect the field order automatically, based on the compression efficiency, TFF vs. BFF.

[umezawa_takeshi]

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

Performance Improvements

UQxx: Speed up


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.0-win.exe) Mac (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.0-mac.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-18.2.0)

[umezawa_takeshi]

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

Others

UQxx: Default value of frame divide count is now same as number of logical processors.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.1-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.1-win.exe) Mac (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.1-mac.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-18.2.1-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-18.2.1)

[yup]

Hi all!
Before encoding I made using VirtualDub mod intermediate file 422 10 bit, but this file do not open AVISource command.
Please advice how solve problem.
yup.

[qyot27]

You need a P210 VFW codec. Good luck with that, though.

Or maybe you could make it work if you pass global OPT_Enable_V210=true (http://avisynth.nl/index.php/Internal_functions#OPT_Enable_V210), so long as you then have a v210 VFW codec.

[yup]

You need a P210 VFW codec. Good luck with that, though.

Or maybe you could make it work if you pass global OPT_Enable_V210=true (http://avisynth.nl/index.php/Internal_functions#OPT_Enable_V210), so long as you then have a v210 VFW codec.
I am add first line
global OPT_Enable_V210 = true
and at AVISource get access violation error.
AVI file without problem open VirtualdubMod, but windows player see only audio.
yup.

[LigH]

Then try a different source filter. Due to the huge index, I would not recommend L-SMASH Works or FFMS2 directly (except you disable caching), but DSS2Mod may work with LAV Filters. Test and tell ...

[yup]

LigH!
Where I could place files
avss.dll and avss_26.dll, in plugin folder?
And where place folder LAV filters? Exist only 32 bit version?
I try open Ut 8 bit files using DSS2Mod and it is work, but not for 10 bits.
yup.

[LigH]

I fear DSS2Mod won't work well for you. The avss.dll is for AviSynth 2.5x only; the avss_26.dll is for AviSynth 2.6x – but does not support additional color spaces.

You don't need to put it in the plugins folder; you can always load a plugin from anywhere, using LoadPlugin() with full path name. But yes, this release was 32 bit only. And that LAV Filters build was as old as the plugin, surely too old to support Ut 10 bit, you would have to substitute it with a current version.

So ... rather FFMS2 or LSW; try with or without caching the video index.

[yup]

LigH!
Thanks for advice.
FFMS2 (64 bit) work, open script and support 10 bit.
yup.

[chummy]

FFMpeg still dont support ULH0? It always encode to ULY0 with "-pix_fmt yuv420p" and i need BT709.

[richardpl]

FFMpeg still dont support ULH0? It always encode to ULY0 with "-pix_fmt yuv420p" and i need BT709.

ULH0 is enabled if you manually set bt709 colorspace with -colorspace switch.

And its FFmpeg, not FFMpeg.

[chummy]

ULH0 is enabled if you manually set bt709 colorspace with -colorspace switch.

And its FFmpeg, not FFMpeg.

My error was to leave colorspace parameter after yuv420p. Now it's fixed and working.

[goemon]

FFmpeg utvideo doesn't support yuv422p10?


ffmpeg version git-2017-12-23-d02289c Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 7.2.0 (GCC)
configuration: --enable-gpl --enable-version3 --enable-sdl2 --enable-bzlib --enable-fontconfig --enable-gnutls --enable-iconv --enable-libass --enable-libbluray --enable-libfreetype --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libopus --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libtheora --enable-libtwolame --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libzimg --enable-lzma --enable-zlib --enable-gmp --enable-libvidstab --enable-libvorbis --enable-libvo-amrwbenc --enable-libmysofa --enable-libspeex --enable-amf --enable-cuda --enable-cuvid --enable-d3d11va --enable-nvenc --enable-dxva2 --enable-avisynth --enable-libmfx
libavutil 56. 6.100 / 56. 6.100
libavcodec 58. 8.100 / 58. 8.100
libavformat 58. 3.100 / 58. 3.100
libavdevice 58. 0.100 / 58. 0.100
libavfilter 7. 7.100 / 7. 7.100
libswscale 5. 0.101 / 5. 0.101
libswresample 3. 0.101 / 3. 0.101
libpostproc 55. 0.100 / 55. 0.100
Encoder utvideo [Ut Video]:
General capabilities: threads
Threading capabilities: frame
Supported pixel formats: rgb24 rgba yuv422p yuv420p yuv444p
utvideo AVOptions:
-pred <int> E..V.... Prediction method (from 0 to 3) (default left)
none E..V....
left E..V....
gradient E..V....
median E..V....

[umezawa_takeshi]

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

New features

Add new codecs which focus on speed (FourCC: UMRA, UMRG, UMY4, UMY2, UMH4, UMH2). Decode only in case of QuickTime components.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-19.0.1-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-19.0.1-win.exe) Mac (zip) (http://umezawa.dyndns.info/archive/utvideo/utvideo-19.0.1-mac.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-19.0.1-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-19.0.1)

[_gl]

@umezawa_takeshi,

thanks for this awesome codec I've been using the 8bit versions for some time. I want to try the Quicktime Pro codecs on Windows now for 10bit, so I downloaded your source code. I managed to get everything working via VC2015 Express (installed Cygwin + devel stuff and the Quicktime SDK), everything except core builds but I'm stuck on assembling the x86 Huffman code:

HuffmanCode_x86.cpp
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s: Assembler messages:
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:110: Error: operand type mismatch for `push'
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:110: Error: operand type mismatch for `pop'
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:227: Error: operand type mismatch for `push'
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:227: Error: operand type mismatch for `pop'
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:375: Error: operand type mismatch for `push'
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:375: Error: operand type mismatch for `pop'
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:523: Error: operand type mismatch for `push'
/cygdrive/c/Users/rd/AppData/Local/Temp/cc8EsSP3.s:523: Error: operand type mismatch for `pop'

Any idea how to fix this?

BTW, you said you never get a request for YUV 10bit 4:4:4 - here's one : ). It's the perfect intermediate format for the video work I do in Premiere. I upsample colour to 4:4:4 and process it in my own plugin software, so I'd often like to have a 4:4:4 intermediate. And I tend to work in YUV natively in Premiere so that is the ideal lossless format for me.

Thanks for considering :)

[LigH]

I am no expert in VS assembly; but the error messages sound (to me, at least) like there are data types not independent of CPU register widths (32 vs. 64 bit code). Just a guess...

[_gl]

I am no expert in VS assembly; but the error messages sound (to me, at least) like there are data types not independent of CPU register widths (32 vs. 64 bit code). Just a guess...

Thanks, yes the issue seems to be that the x86 code is compiled on x64 Cygwin here, so some of the 32bit register assumptions don't work. The trick is to compile it in x86 mode by adding the -m32 flag to:

utv_core -> HuffmanCode_x86.cpp -> Properties: Custom Build Tool -> Command line

= c:\cygwin\bin\env PATH=/bin c:\cygwin\bin\g++ -std=c++11 -O2 -masm=intel -m32 -c -o $(IntDir)%(Filename).obj %(Identity)

I assume this isn't an issue when compiling on a x86 Cygwin.

[_gl]

OK, I've got the QT codecs built, but I can't export to them from inside Premiere CS6 (Windows). On the first export attempt to Pro RGB I get the generic 'Error compiling movie - Unknown Error'.

On the second, the file is in use by something and can't be overwritten.. That's Adobe QT32 Server.exe, which has clearly not released the file from the first attempt.

Is this actually known to work?

EDIT: if anyone wants to try them, PM me your email address.

[_gl]

OK, I've got the QT codecs built, but I can't export to them from inside Premiere CS6 (Windows). On the first export attempt to Pro RGB I get the generic 'Error compiling movie - Unknown Error'.

(EDIT:wrong, ignore)Ah, sorted. I was forcing Premiere to use a floating point render pipe via my own plugin's code (as it wasn't choosing float for a prior 10bit uncompressed AVI export and so giving me lower visual quality) - so my plugin did not allow 8bit formats at all. For some reason this seems to have caused the export failure even though it works for other export types.

Strange thing is that when I re-enabled 8bit support, it's now exporting fine with Premiere choosing a floating point 709 internal pipeline, which is exactly what I wanted (so it should have worked before - oh well :)).[/s]

Great to see that the LAV filters support playback of the 10bit formats.

[_gl]

... no that wasn't it. While some exports to the Pro RGB codec work, others still fail with the same 'Unknown Error' right at the start. Same thing happens in Premiere and Adobe Media Encoder CS6. All footage is 720p.

Any way to troubleshoot this?

[_gl]

Apologies for the post overload, but the good news is I've got the Pro RGB QT codec to work in Premiere CS6!

My first 'successful' render was actually to a different UT codec by mistake, so it never actually worked. Following the thread, I added these to

C:\Users\<user>\AppData\Roaming\Adobe\Common\MediaCoreQTCodecRulesCS6.xml :


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

This enabled additional bit depth options in the Premiere Export dialog. Instead of the two checkboxes for 24bit and 32bit, I now have a drop-down menu for 24 / 32 / 48 / 64bit.

Rendering at 32bit fails as before - but 48bit and 64bit work! MediaInfo confirms that the codec of the resulting file is UQRG.

LAV can also play this back (be sure to enable UTVideo in the video codec format options).

[_gl]

.. there is one catch. The encoded Pro file will not play back correctly inside Premiere when the above 'decode' line is added to MediaCoreQTCodecRulesCS6.xml, I just get a black screen. However if I remove that line, then it plays back fine.

I'm concerned though that it may not deliver the full 10bits of data this way. Anyone want to test it? (PM me for the compiled QT codec if needed).

[umezawa_takeshi]

@_gl

I'm sorry for being late. Are your problems solved?

I'm not familiar with MediaCoreQTCodecRules<version>.xml --- I just heard that the codec will work when we write the XML fragment to the file, and I don't understand what the fragment actually means...

[_gl]

Hi @umezawa_takeshi ,

the Pro RGB QT codec now fully works for exports inside Premiere CS6, but only with the 'encode' additions to MediaCoreQTCodecRules, and when choosing 48 or 64 bit depth in the Export dialog (16 and 24 bit fail).

For imports, Premiere decodes the clip fine when the 'decode' section is NOT added to MediaCoreQTCodecRules. However I don't know if it's delivering the full 10bit data this way.

If the 'decode' section is added, then it only draws black frames.

I assume the encode/decode additions mean that Premiere will deliver and receive the b64a format to/from the codec? But the 'decode' entries don't work strangely.

[umezawa_takeshi]

UtVideo Pro variants are not able to accept 8bit formats, neither in encoding nor in decoding. If Premiere can read an UQRG file and a (non-blank) video is displayed, it should be 10bit. --- Of course, there is a possibility that Premiere or QT converts 10bit clip to 8bit clip.

[kolak]

Not sure about Premiere, but AE can take b64a pixel format if codec provides it and then there is no conversion to 8bit.
In my tests Premiere wasn't exactly the same. I think in case of Premiere you may have more luck if decoder can provide r4fl pixel format.

[umezawa_takeshi]

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

New features

UMxx: Add temporal compression.

Performance Improvements

UMxx: Speed up


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.0.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.0.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.0.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.0.0)

Added temporal compression, which is especially effective to static (= small transition) video. It is not effective to dynamic video because no "advanced" process like motion compensation.

Mac version is not released this time. When a temporal compressed video file is played with QuickTime Player, displayed video is corrupted and the player crashed soon. I could not find solution for this problem.

[GMJCZP]

Arigato, umezawa_takeshi-sama.

[umezawa_takeshi]

Today, 2018-04-18 is the 10th anniversary from the first public release of Ut Video Codec Suite (http://umezawa.dyndns.info/wordpress/?p=292). The first release has only YUV422 variant and VCM interface.

Originally I started to develop UtVideo because Huffyuv lacked performance while HD-capturing Ace Combat 6 (Xbox 360). Since then, UtVideo has been introduced to the world --- yes, this forum thread ---, compatible implementation has been added to FFmpeg/Libav, and UtVideo is now used in various scenes.

UtVideo itself has also evolved as follows:

continually optimized
more types of internal formats
more types of codec interfaces
added 10bit/channel variants
added new compression algorithm/principle


What will happen in the next 10 years?

[Sparktank]

Outstanding!

I love a good underdog story. :)

Definitely happy to have this as an option along with other lossless codecs.

Keep up the work. Can't wait to see the future.

[GMJCZP]

Today, 2018-04-18 is the 10th anniversary from the first public release of Ut Video Codec Suite (http://umezawa.dyndns.info/wordpress/?p=292). The first release has only YUV422 variant and VCM interface.

Originally I started to develop UtVideo because Huffyuv lacked performance while HD-capturing Ace Combat 6 (Xbox 360). Since then, UtVideo has been introduced to the world --- yes, this forum thread ---, compatible implementation has been added to FFmpeg/Libav, and UtVideo is now used in various scenes.

UtVideo itself has also evolved as follows:

continually optimized
more types of internal formats
more types of codec interfaces
added 10bit/channel variants
added new compression algorithm/principle


What will happen in the next 10 years?

The sky is the limit, congratulations!

[LigH]

:thanks:

Not your most active user, but a grateful one, nevertheless.

[Emulgator]

10 Years ! Congratulations & many thanks !
Time for a donation !
Done.

[WorBry]

10 Years !

Suddenly I feel old.

Yep, UTVideo has come a long way from those humble beginnings. Thanks for all of your work and dedication.

[umezawa_takeshi]

I did benchmarking about one and a half years ago. Since UtVideo is enhanced in this period, I do benchmarking again.

Please see

http://umezawa.dyndns.info/wordpress/?p=6934 (English version) or
http://umezawa.dyndns.info/wordpress/?p=6911 (Japanese version).

[umezawa_takeshi]

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

New features

UQRG: Add suppport of r210 input/output.

Bug fixes

all: Wrong behavior in encoder configuration resetting process.
UQxx: May crashed if video width is not multiple of 8.
UQRG: Alpha value is wrong in b64a output.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.1.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.1.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.1.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.1.0)

[umezawa_takeshi]

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

Performance Improvements

ULxx: Speed up encoding on x64.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.2.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.2.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.2.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.2.0)

[mzso]

Hi!

Is there an ecoding guide around? There are so many variants now... Should I use RGB or YUV444? Does the latter entail quality loss?
How is the T2 variant different? Is the "pro" codec only different in encoding in higher bit depth?

PS:
By the way, does ffmpeg have it's own implementation or uses original codec?

[mzso]

I've been testing with ffmpeg. Is it normal for 444 to be so much faster with much better multi-processing utilization? It's close to five times faster.
YUV444:
Output #0, matroska, to 'ut-444.mkv':
Metadata:
encoder : Lavf58.25.100
Stream #0:0: Video: utvideo (ULH4 / 0x34484C55), yuv444p(pc, bt709/bt709/unknown), 1600x1200, q=2-31, 200 kb/s, 50 fps, 1k tbn, 50 tbc (
default)
Metadata:
DURATION : 00:01:44.980000000
encoder : Lavc58.43.101 utvideo
frame= 1815 fps=169 q=-0.0 Lsize= 2247617kB time=00:01:44.96 bitrate=175422.1kbits/s speed=9.75x
video:2247527kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.004034%

https://abload.de/thumb/ut-444ekkd9.png (http://abload.de/image.php?img=ut-444ekkd9.png)
RGB:
Output #0, matroska, to 'ut-rgb.mkv':
Metadata:
encoder : Lavf58.25.100
Stream #0:0: Video: utvideo (ULRG / 0x47524C55), gbrp, 1600x1200, q=2-31, 200 kb/s, 50 fps, 1k tbn, 50 tbc (default)
Metadata:
DURATION : 00:01:44.980000000
encoder : Lavc58.43.101 utvideo
frame= 1815 fps= 37 q=-0.0 Lsize= 2427476kB time=00:01:44.96 bitrate=189459.8kbits/s speed=2.16x
video:2427386kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003734%


https://abload.de/thumb/ut-rgbnjjvy.png (http://abload.de/image.php?img=ut-rgbnjjvy.png)

[richardpl]

That may be because of on which compiler it was build. Looks like auto-vectorizations are not enabled when using gbrp conversion within swscale is slow.

[mzso]

I also noticed a problem. I couldn't play back the 444 file with MPC or PotPlayer. I only got a black screen with the loaded ULH4 Decoder DMO filter.
Apparently LAV doesn't support this format. Because for RGB LAV loads and the video plays fine.

[mzso]

That may be because of on which compiler it was build. Looks like auto-vectorizations are not enabled when using gbrp conversion within swscale is slow.

Huh. Oh well. Not much I can do about that. I don't compile builds myself.

[poisondeathray]

Actual encode speeds for the VFW/VCM version seem slower than they should be (compared to say, ffmpeg)

eg. 1920x1080 4:2:0 to ULH0 (709), blankclip in avisynth to prevent source decoding bottleneck (check with avsmeter, ffmpeg, ssd to reduce any I/O bottleneck . Tried with vdub, vdub2 , or avs2avi CLI . Tried older UT Video codec versions . Tried other fourcc (ULY0, 601) .

Looks like a threading issue in task manager . Maybe ~60-65fps . But magicyuv VFW/VCM same setup might get 3x the speed (and -c:v utvideo in ffmpeg about 3x the speed) both look to make use of threading more efficiently

Any ideas ? or what is the proper way to use VCM/VFW version ?

[poisondeathray]

RGB:
Output #0, matroska, to 'ut-rgb.mkv':
Metadata:
encoder : Lavf58.25.100
Stream #0:0: Video: utvideo (ULRG / 0x47524C55), gbrp, 1600x1200, q=2-31, 200 kb/s, 50 fps, 1k tbn, 50 tbc (default)
Metadata:
DURATION : 00:01:44.980000000
encoder : Lavc58.43.101 utvideo
frame= 1815 fps= 37 q=-0.0 Lsize= 2427476kB time=00:01:44.96 bitrate=189459.8kbits/s speed=2.16x
video:2427386kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.003734%




maybe other bottleneck like decoding bottleneck ? What is your RGB source format ? What is the source decoding speed only ?

eg.
ffmpeg -i rgbsource.ext -an -f null NUL


I get about 5-6x faster for 1920x1080 RGB for actual encoding ULRG in absence of source decoding bottleneck

[mzso]

Actual encode speeds for the VFW/VCM version seem slower than they should be (compared to say, ffmpeg)

Huh? My experience is the polar opposite. FFmpeg is a lot slower. Not just with UT but with x264vfw as well.

maybe other bottleneck like decoding bottleneck ? What is your RGB source format ? What is the source decoding speed only ?

eg.
ffmpeg -i rgbsource.ext -an -f null NUL


I get about 5-6x faster for 1920x1080 RGB for actual encoding ULRG in absence of source decoding bottleneck

It's highly unlikely that the decoding source is relevant. CPU utilization wasn't near full. As you can see the core utilization is pretty poor also.
I deleted the files since then but the source was either an ultrafast preset AVC or another ut-video file. (from an SSD) Both decode really fast.

I guess richardpl may be right that ffmpeg is slow. (for whatever reason)

[poisondeathray]

Huh? My experience is the polar opposite. FFmpeg is a lot slower. Not just with UT but with x264vfw as well.

What kind of speeds with UT VFW ? for 4:2:0 and RGB ?

Another person in another forum reported the slow VFW speeds too, that's why I'm double checking this




I guess richardpl may be right that ffmpeg is slow. (for whatever reason)

Not for me. ~180fps for 1920x1080 rgb source encoding to UT RGB (ULRG)

And if I pipe gbrp directly I get ~200fps , since ffmpeg doesn't packed rgb to planar rgb conversion

[mzso]

What kind of speeds with UT VFW ? for 4:2:0 and RGB ?

Another person in another forum reported the slow VFW speeds too, that's why I'm double checking this




Not for me. ~180fps for 1920x1080 rgb source encoding to UT RGB (ULRG)

And if I pipe gbrp directly I get ~200fps , since ffmpeg doesn't packed rgb to planar rgb conversion

I didn't test everything only what I shared. Where RGB was a lot slower.
VFW I could only check by looking at the CPU usage graph, but wasn't as impaired as ffmpeg in RGB.


Not for me. ~180fps for 1920x1080 rgb source encoding to UT RGB (ULRG)

And if I pipe gbrp directly I get ~200fps , since ffmpeg doesn't packed rgb to planar rgb conversion

What sort of ffmpeg build are you using? Your own? I only ever use the zeranoe builds.

Do you check the resulting file? Without using out_color_matrix and out_range=pc the files are borked. appear with the wrong color and become limited ranged...
I made quick test.
With your cli I got: speed= 14x for the source file

ffmpeg -i D:\Felvétel\ePSXe_2019_03_12_13_02_25_790.mkv -an -vcodec utvideo UT-rgb.mkv:
frame= 1181 fps=131 q=-0.0 Lsize= 1817113kB time=00:00:59.68 bitrate=249401.7kbits/s speed= 6.6x

ffmpeg -i D:\Felvétel\ePSXe_2019_03_12_13_02_25_790.mkv -an -pix_fmt yuv444p -vcodec utvideo UT-444-borked.mkv:
frame= 1181 fps= 54 q=-0.0 Lsize= 1609549kB time=00:00:59.68 bitrate=220913.2kbits/s speed=2.71x

ffmpeg -i D:\Felvétel\ePSXe_2019_03_12_13_02_25_790.mkv -pix_fmt yuv444p -vf scale=out_color_matrix=bt709:out_range=pc -color_range pc -colorspace bt709 -color_primaries bt709 -vcodec utvideo UT-444-proper.mkv
frame= 1181 fps= 38 q=-0.0 Lsize= 1671630kB time=00:00:59.68 bitrate=229433.9kbits/s speed=1.94x

I guess I mixed up the results before. YUV is slower. And a lot slower still when using the scale options. I don't know what ffmpeg is exactly doing, but I think it scales pointlessly for me to get a proper result. Which seems superfluous since the source is already in a proper full range RGB format...
(Someone suggested using -vf scale for this when I was unable to encode proper full range video. I know of no other fix...)

[poisondeathray]

What sort of ffmpeg build are you using? Your own? I only ever use the zeranoe builds.

I used zeranoe for those tests too


Do you check the resulting file? Without using out_color_matrix and out_range=pc the files are borked. appear with the wrong color and become limited ranged...
I made quick test.

Yes. I removed those extraneous variables for the testing. You're confusing the test results, because of colorspace conversions and swscale. (ie. you're not just testing the utvideo encoding speed, but a bunch of other operations too - you have other bottlenecks)

e.g. If I wanted to test RGB encoding, I fed it RGB. If I want to test 8bit 4:2:0 , I fed it 8bit 4:2:0.

EDIT: and for YUV 444 (ULH4 , 709) , it's even faster than RGB input/encoding in ffmpeg , I get about 210-220 fps . It's a valid file (VLC doesn't support it, but it decodes corrrectly with potplayer, mpv, ut official decoder, ffplay etc...)



Why is VFW so slow for encoding ? I made sure to use "fast recompress" in vdub , and avs2avi feeds same colorspace .

There used to be known DEcoding differences . The ffmpeg encoded variant was about 2/3 the speed for decoding a few years back using the same decoder

[umezawa_takeshi]

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

Performance Improvements

ULxx: Speed up encoding to / decoding from native packed formats.

Others

ULxx: "Assume interlace video" is now non-recommended feature.
Deleted information in readme about QuickTime components, which are already discontinued practically.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.3.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.3.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.3.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.3.0)

[umezawa_takeshi]

Is there an ecoding guide around?


Currently, no.


There are so many variants now... Should I use RGB or YUV444? Does the latter entail quality loss?


They are completelty lossless if and only if the input/output formats are same as its internal format. If not, they are lossless except colorspace conversion noise.


How is the T2 variant different?


Compared to non-T2 variant,
* T2 is faster in most cases.
* T2 has temporal compression mode.
* T2's compression ratio is lower for noisy images and higher for something like CGs.


Is the "pro" codec only different in encoding in higher bit depth?


"Pro" variants support higher bit depth and less functionality.


By the way, does ffmpeg have it's own implementation or uses original codec?


Recent FFmpeg/Libav use their own implementation.

[mzso]

@umezawa_takeshi
Thanks for the info.

[mzso]

What effect does the temporal compression option has? Does it improve compression ratio (at the cost of or without significantly affecting performance?), or will it improve performance(at what cost?) ?

[mzso]

By the way, why can't UT video play back it's own format?
Both "ULH4 Decoder DMO filter" and "UMRG Decoder DMO" only produce a blackscreen when I tried playing them back. So can't in anyway view the recorded files.

[mzso]

By the way, why can't UT video play back it's own format?
Both "ULH4 Decoder DMO filter" and "UMRG Decoder DMO" only produce a blackscreen when I tried playing them back. So can't in any way view the recorded files.

[umezawa_takeshi]

What effect does the temporal compression option has?

The temporal compression is slower than non-temporal one in most case. Of course, its compression ratio depends on source video. Use temporal compression for static video.

By the way, why can't UT video play back it's own format?
Both "ULH4 Decoder DMO filter" and "UMRG Decoder DMO" only produce a blackscreen when I tried playing them back. So can't in anyway view the recorded files.

That is strange. What application did you use?

[mzso]

That is strange. What application did you use?

MPC-HC, MCP-BE, Potplayer. I tried ULH4 and UMRG and in each case I only got a black screen with playback not starting. Seeking didn't do anything either, more black and no playback.

(By the way, why the excessive amount of fourCC identifiers? Other codecs that I know of that support multiple color formats of and have multiple compression methods only have one or two, such as AVC.)

[umezawa_takeshi]

MPC-HC, MCP-BE, Potplayer. I tried ULH4 and UMRG and in each case I only got a black screen with playback not starting. Seeking didn't do anything either, more black and no playback.

I tried them, but all work file.

(By the way, why the excessive amount of fourCC identifiers? Other codecs that I know of that support multiple color formats of and have multiple compression methods only have one or two, such as AVC.)

In order to reduce possibility of color information loss caused by mis-configuring codecs.

[LigH]

DirectShow is a box of candy; you may have to trace the graph to discover if there is a "filter in the middle" ruining the result. Or it might even be the graphic driver pretending to support a display feature it actually did not implement well. I guess. Don't quote me... :o

[mzso]

DirectShow is a box of candy; you may have to trace the graph to discover if there is a "filter in the middle" ruining the result. Or it might even be the graphic driver pretending to support a display feature it actually did not implement well. I guess. Don't quote me... :o

I doubt there is a filter in the middle. These apps all show what filters are loaded.
MPC-HC even allows copying the list:
Filters currently loaded:
- Default DirectSound Device
- madVR
- Audio Switcher
- UMRG Decoder DMO
- LAV Audio Decoder (internal)
- LAV Splitter Source

After I remove audio, the playback does start, but I still only get a black screen. These filters are loaded:
Filters currently loaded:
- madVR
- UMRG Decoder DMO
- LAV Splitter Source

[mzso]

Okay. So, since there's precious little that's loaded, I tried changing the renderer and it turns out that it only doesn't work with madVR. For whatever reason.

[umezawa_takeshi]

I tried madVR + MPC-HC (x64). This combination makes blank output, as you said.

According to my additional investigation, this is because madVR's behavior is strange and is not compatible with UtVideo's DMO implementation. I am not responsible for it.

[mzso]

I tried madVR + MPC-HC (x64). This combination makes blank output, as you said.

According to my additional investigation, this is because madVR's behavior is strange and is not compatible with UtVideo's DMO implementation. I am not responsible for it.

Well, you can talk it out with the madVR dev, I guess: madVR's topic (https://forum.doom9.org/showthread.php?t=146228)

[Taurus]

@mzso:
madVR + MPC-HC (x64) + MPC-HC (x32) are doing fine with LAV Filters.
I'm using this all the time.
Only the UTVideo Decoders give a black hole :mad::D.
And this is how it is for a long time.
I don't even remember when this came first to my attention..
But any way:
A Big Thank You to Umezawa_Takeshi for maintaining this great
Encoder and Decoder :thanks:!

[LigH]

I bet madshi will have reasons to make madVR behave as it does ... if you two talk together, you may find a way to achieve compatibility.

[Tima]

I see interlaced encoding got deprecated in the latest release.

Can we expect that at least decoding will not be dropped subsequently?

For VHS archival purposes, I currently use Median Interlaced mode, as it gives ~10% better compression.
Also, (and it's _very_ convenient) my player/decoder suite (K-Lite) invokes deinterlacing automatically, that does not happen for the non-interlaced mode (and AVI format doesn't allow to store interlaced flag externally).

Compression results for interlaced video (VHS capture, TFF, if it matters):

Gradient 1793 MB 100%
Median 1689 MB 94%
Left 1669 MB 93%
Left Interlaced 1669 MB 93%
Gradient Interlaced 1589 MB 89%
Median Interlaced 1528 MB 85%


Relative savings are significant in all modes except Left:

Gradient 1793 MB 100%
Gradient Interlaced 1589 MB 89%

Median 1689 MB 100%
Median Interlaced 1528 MB 90%

Left 1669 MB 100%
Left Interlaced 1669 MB 100%

[umezawa_takeshi]

I have no plan to remove interlace mode feature from ULxx. Please don't worry.

[umezawa_takeshi]

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

New features

Add feature to disable specific codec interface based on process name or completely.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.4.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.4.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.4.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.4.0)

If you set UTVIDEO_DISABLE_interface_feature environment variable to 1, the feature on the interface is completely disabled. Interface is VCM or DMO, and feature is ENCODER, DECODER or QUERY (QUERY is only for VCM).

You can also use UTVIDEO_PROCESSBLACKLIST_interface_feature environment variable to disable the feature on the interface for specific program. Enumerate EXE file names separated with PATH environment separator (; on Windows). If each name ends with path separator (\ on Windows), the name is directory. If each name does not contain path separator, the name is file's base name. Otherwise, the name is file's full path name. Note that case sensitivity on name comparison follows system's behavior. i.e. it is case insensitive on Windows.

Examples:

set UTVIDEO_DISABLE_DMO_DECODER to 1 to disable DMO decoder completely.
set UTVIDEO_PROCESSBLACKLIST_DMO_DECODER to D:\;C:\program files\windows media player (x86)\wmplayer.exe;foo.exe to disable DMO decoder for

the programs under D: drive,
Windows Media Player in C:\program files (x86)\windows media player and
all programes named foo.exe.

[LigH]

https://cosgan.de/images/smilie/froehlich/e035.gif
Exciting feature!

[umezawa_takeshi]

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

Performance Improvements

UMxx: Speed up encoding to / decoding from native packed formats in case of intraframe compression.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.5.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.5.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.5.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.5.0)

[umezawa_takeshi]

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

Bug fixes

UMRG, UMRA: In pre-AVX2 environment, intraframe encoding result is wrong when the remainder of width divided by 64 is 32.


The version affected by this bug is 20.5.0 only.

License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.5.1-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.5.1-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.5.1-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.5.1)

[Saturation]

Hi, guys.
I have a problem.
Starting from codec version 20.4.0, when was added new feature "to disable specific codec interface based on process name or completely", I can't open codec's configuration window in Vegas Pro NLE.
"Configure" button is inactive.
For example, there is no such problem with VirtualDub.
So I stuck with codec version 20.3.0.
Is there any possibility to do something with that?

Umezawa Takeshi wrote, that everyone can manually enable/disable this feature (if I understand correctly), but I am not a programmer and absolutely don't know how to do that.

[umezawa_takeshi]

Probably Vegas passes wrong option to codec. (i.e. it is Vegas's problem)


Technical explanation:

Since 20.4.0, VCM version of UtVideo strictly checks the option that passed to ICOpen (https://docs.microsoft.com/en-us/windows/win32/api/vfw/nf-vfw-icopen). If wMode parameter is not ICMODE_COMPRESS, codec clients cannot call ICConfigure, the function to configure encoding option.

[Saturation]

Then it seems, that UtVideo codec version 20.3.0 is the last for me.
Very sad.
:-(

[umezawa_takeshi]

Today, UtVideo drops support of 32bit Windows.

NOTE: 32bit codecs running on 64bit Windows are still supported.

[djonline]

I found that UTVideo decoder is not good as Magic. It produce 4:2:0 non smooth line on red edge. It seems like chrome not interpolated after decode.

I apply Unsharp mask in Premiere with amount 350 to show differences.
Left - Magic, Right - UTVideo.
Look at dress/background line, it has vertical pixels in right picture.
https://d.radikal.ru/d01/1909/9f/c14e9f4a2dfb.pnghttps://c.radikal.ru/c13/1909/ae/63cfb27623c6.png

[umezawa_takeshi]

Yes.

For example, in case of internal format is YUV420 (like ULY0) and input/output format is RGB:
- While encoding, chroma is the average of four pixels.
- While decoding, those four pixels use same chroma (i.e. not interpolated).

[djonline]

I work with video in Premiere 2019, there is RGB internal decoding. Screenshots from Premiere too.
What to do to make ut420 decode like magic420 ?

UTVideo 420 - bad chrome upsampling (look to left)
https://a.radikal.ru/a40/1909/1e/d5655ac562ca.png

Magic 422 - some bad chrome upsampling, but better that ut420
https://b.radikal.ru/b03/1909/82/cd61b1a0564b.png

Magic 420 - good chrome upsampling
https://d.radikal.ru/d38/1909/07/1125ef31311c.png

[umezawa_takeshi]

Suppose interpolation is added, there are some implementation options:

- While decoding, how to decide whether to interpolate? (decoders configuration / flag in encoded data)
- There are several interpolation methods (MPEG1, MPEG2, ...). Which one should be adopted?
- How to deal with old format data which is created by old codec that doesn't care of interpolation.

What is the best / preferable choice ?


In case of MagicYUV:
- Encoders have interpolation configuration (ON/OFF).
- Decoders don't have the configuration.
- There is single interpolation method, probably (there is no configuration to select interpolation method)

[umezawa_takeshi]

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

Performance Improvements

UQRG, UQRA: Speed up encoding and decoding.
UQxx: Speed up decoding.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.6.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.6.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.6.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.6.0)

[umezawa_takeshi]

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

Bug fixes

Indeterminate behavior in case of frame divide count larger than 64.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.6.1-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.6.1-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-20.6.1-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-20.6.1)

Note that the frame divide count is never larger than 64 if "Same as # of logical processors" in the configuration dialog is checked, even if the actual number of logical processors is larger than 64.

[jpsdr]

So, the last version supporting 32 bits OS is the 20.5.1 ?

Edit Corrected typo...

[umezawa_takeshi]

So, the last version supporting 32 bits OS is the 2.5.1 ?

I mean "UtVideo supports 32bit Windows" as "I care about whether UtVideo runs on 32bit Windows or not". No version supports 32bit Windows now.

Probably current UtVideo can be installed to / runs on 32bit Windows, but I neither guarantee it nor confirm it.

[umezawa_takeshi]

Today, UtVideo drops support of Windows 7.

[Emulgator]

Sorry to hear that.

[umezawa_takeshi]

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

New features

Add a codec whose internal format is YUV420 10bit (FourCC: UQY0).
UQY2: Add support of YUV422P16 input/output.

Performance Improvements

UQY2: Speed up decoding to v210 a little.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.0.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.0.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.0.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-21.0.0)

[umezawa_takeshi]

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

New features

UQY2: Add support of P210/P216 input/output.
UQY0: Add support of P010/P016 input/output.

Performance Improvements

UQY2: Speed up encoding from / decoding to YUV422P16.
UQY0: Speed up encoding from / decoding to YUV420P16.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.1.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.1.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.1.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-21.1.0)

[umezawa_takeshi]

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

Performance Improvements

ULxx, UQxx: Speed up encoding and decoding for high compression ratio video.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.0-readme.en.html) / Windows (exe) (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.0-win.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-21.2.0)

[Music Fan]

Hi,
I couldn't install last version (21.2.0) on XP 32 bit, is it normal ?

[richardpl]

XP support is removed and also 7 support, it is all explained.

[Taurus]

XP support is removed and also 7 support, it is all explained.
It installs quite well on Win7 64bit.
Dont know about XP.

[jpsdr]

For now, it still installs on Win7 x86/x64. The last version working on XP is 13.3.1.

[Music Fan]

Ok thanks, I will have to continue with Lagarith.
That's for an old capture card on an old pc, I'm not sure it could run under Windows 7 64 bit.

XP support is removed and also 7 support, it is all explained.
I didn't read the whole topic but I saw this in the first post ;
Minimum Requirement (from readme file)

-OS: Windows XP or later

[umezawa_takeshi]

As mentioned by others, Windows 7 and older and 32bit Windows are not supported now.

I cannot update the first post because it is posted by another person.

[umezawa_takeshi]

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

Others

Excluded utv_logc.exe from installer.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.1-readme.en.html) / Windows exe installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.1-win.exe) zip package (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.1-win.zip) utv_logc.exe (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.1-win-utv_logc.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.2.1-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-21.2.1)

In addition, experimental zip package is available. I don't explain the usage of zip package more than written in readme-zip.txt .

FIX: In uninstall procedure, the batch file to execute is uninstall.bat. Not install.bat (written in readme-zip.txt), of course.

[umezawa_takeshi]

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

Performance Improvements

ULxx, UQxx: Speed up encoding a little.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.0-readme.en.html) / Windows exe installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.0-win.exe), zip package (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.0-win.zip), utv_logc.exe (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.0-win-utv_logc.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-21.3.0)

Note: Huffman decode routine is updated. If you find any problem in ULxx/UQxx decoding, please report it.

[umezawa_takeshi]

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

Others

Added tooltips to configuration dialogs.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.1-readme.en.html) / Windows exe installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.1-win.exe), zip package (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.1-win.zip), utv_logc.exe (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.1-win-utv_logc.exe) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-21.3.1-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-21.3.1)

[vigan1]

Thank you it's the best codec for realtime encoding !
UTvideo T2 is the fastest.

It is supported on ffmpeg ? Or only T1 in FFmpeg ?

[umezawa_takeshi]

Thank you it's the best codec for realtime encoding !
UTvideo T2 is the fastest.

It is supported on ffmpeg ? Or only T1 in FFmpeg ?

As far as I know, T2 encoding is not supported on FFmpeg. T2 decoding is supported.

[vigan1]

Thank you, they should add it, your codec is the best.
I know it's hard and lonely sometime to work on a project, for free, so please remember that your work is very highly appreciated.
And I hope you will have the best life, be happy.
Thank you.

When it's hard don't give up, have a nice day!

[umezawa_takeshi]

Thank you for your encouragement. You too.

[Richard1485]

The fact that this codec is still being actively developed is fantastic. Thanks for the update!

[umezawa_takeshi]

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

New features

UQxx: Add "Predict Gradient" intra-frame prediction method.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.0.0-readme.en.html) / Windows exe installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.0.0-win.exe), zip package (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.0.0-win.zip), logger tool (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.0.0--log-win.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.0.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-22.0.0)

[umezawa_takeshi]

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

New features

ULY0, ULH0: Add NV12 input/output.

Performance Improvements

Speed up decoding to RGB32/RGBA and YUY2/UYVY from native internal format.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.1.0-readme.en.html) / Windows exe installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.1.0-win.exe), zip package (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.1.0-win.zip), logger tool (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.1.0--log-win.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.1.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-22.1.0)

[umezawa_takeshi]

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

Performance Improvements

UQxx: Speed up encoding / decoding in case of Predict Gradient.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.2.0-readme.en.html) / Windows exe installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.2.0-win.exe), zip package (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.2.0-win.zip), logger tool (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.2.0--log-win.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.2.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-22.2.0)

[jeffk]

Hi, Thanks for your codec, it is amazingly fast.

I feel that the "Not recommended" about interlaced video is a bit brutal, because if really encoding Interlaced Video we dont know if we need to use it.

Is it not recommended for progressive, not recommended at all ?

At the moment i'm working on Interlaced video I dont know if I must/need/should check it.

[jpsdr]

Not recommended is for allways checking this whatever your video is. Otherwise it will assume video is interlaced, and encode accordingly, wich will result in less efficient for progressive video.
If it's always checked, encoding of progressive video will be less efficient.
If it's always unchecked, encoding of interlaced video will be less efficient.
If you think there is more progressive than interlaced videos, you'll not recommend the interlaced mode.
The best is to check it when you have interlaced video, and uncheck when you have progressive.
If you're dealing more often with interlaced than progressive video, and don't want to have to configure each time, it will be more efficient to check it.

[umezawa_takeshi]

The reason I wrote that the option is not recommended is simply because it is slow and I won't optimize it anymore. There is nothing wrong with using this option if there is any reason.


If you are working with interlaced video, you can achieve higher compression ratio with the option.
If you use ULY0/ULH0 and its input/output format is not YUV 4:2:0, you should use the option correctly because vertical down/up sampling algorithm depend on whether the video is interlaced or not.


Of course, you should not use the option if you are working with progressive video.

[Richard1485]

Maybe it would be better to label the interlaced option as "slow". It is obvious that the option should be used only for interlaced content, but as things stand the user might assume that it is not recommended even for interlaced content, or that there is some issue with interlaced video in UT VIdeo, which is not the case.

[LigH]

Maybe "Don't enable by default" or similar...

[umezawa_takeshi]

All right. I will fix wording in the next release.

[umezawa_takeshi]

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

Performance Improvements

UMxx: Speed up input/output on AVX512-VBMI2 capable processors.

Others

Updated supported environment and recommended environment.


License (GPLv2) (http://umezawa.dyndns.info/archive/utvideo/gplv2.txt) / readme (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.3.0-readme.en.html) / Windows exe installer (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.3.0-win.exe), zip package (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.3.0-win.zip), logger tool (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.3.0-log-win.zip) / source code (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.3.0-src.zip) / GitHub (https://github.com/umezawatakeshi/utvideo/releases/tag/utvideo-22.3.0)

[mzso]

Does ffmpeg include the official codec, or do they have their own UT-Video implementation?

Edit:
I seeem to have a major issue when trying to record with MSI afterburner. No video is recorded.

[GAP]

Can anyone explain to me what the various options of UTVideo mean? And what they do? I am confused.

[GMJCZP]

Please read here (https://www.free-codecs.com/download/ut_video_codec_suite.htm) and here (http://umezawa.dyndns.info/archive/utvideo/utvideo-22.6.0-readme.en.html).

[mzso]

Hello!

Why is UT-Video RGB missing from the latest version (versions?)?

There are only YUV formats available and T2-RGB.

Edit:
Removed resolved stuff.

[mzso]

I found this:
https://forums.guru3d.com/threads/msi-afterburner-external-vfw-codec-recording-not-working.432000/#post-5871279
"Hi. It turns out the Ut Video VFW encoder is incompatible with Afterburner since version 20.4.0. I investigated and managed to find the offending commit: https://github.com/umezawatakeshi/utvideo/commit/344e70e893f8439998e863ad9a2f951ad4a111db (https://forums.guru3d.com/threads/msi-afterburner-external-vfw-codec-recording-not-working.432000/#post-5871279)
After reverting this commit, I was able to successfully build version 22.2.0 (i.e. the latest version at the time of writing) and it works alright with Afterburner."

Is this still broken? (On whoever's side)

[Tima]

I found this:
https://forums.guru3d.com/threads/msi-afterburner-external-vfw-codec-recording-not-working.432000/#post-5871279
[/URL]

Is this still broken? (On whoever's side)

I've encountered a similar issue with Vegas:

[url]https://github.com/umezawatakeshi/utvideo/issues/43 (https://forums.guru3d.com/threads/msi-afterburner-external-vfw-codec-recording-not-working.432000/#post-5871279)

[Thundik81]

Ut Video v23.2.0
http://umezawa.dyndns.info/archive/utvideo/utvideo-23.2.0-readme.en.html
http://umezawa.dyndns.info/archive/utvideo/utvideo-23.2.0-win.zip
http://umezawa.dyndns.info/archive/utvideo/utvideo-23.2.0-src.zip
<
http://umezawa.dyndns.info/archive/utvideo/?C=M;O=D