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

[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