Ut Video Codec Suite - a new lossless video codec for Windows! [Archive] - Page 11

LigH

2nd May 2016, 08:00

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

2nd May 2016, 09:31

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

2nd May 2016, 10:27

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

3rd May 2016, 14:29

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

3rd May 2016, 23:32

Seams to be working now (tested Mac version).

foxyshadis

7th May 2016, 00:55

Bloax

8th May 2016, 11:26

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

8th May 2016, 17:25

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

8th May 2016, 22:54

@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

9th May 2016, 12:20

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

9th May 2016, 16:20

@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

16th May 2016, 00:10

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

24th May 2016, 10:45

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

24th May 2016, 16:01

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

25th May 2016, 03:43

Hmmm, the latest version of the DMO decoder makes regsvr32 crash. Version 15.5.0 still works OK.

dipje

31st May 2016, 15:06

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

31st May 2016, 15:36

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

31st May 2016, 16:36

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

31st May 2016, 17:13

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

1st June 2016, 07:46

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

4th July 2016, 15:23

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

4th July 2016, 19:48

Takeshi, this build it works (apparently) in XP SP3 but obtain the same error as in post # 503.

umezawa_takeshi

5th July 2016, 15:17

Support of Windows XP is dropped since version 14.0.0.

dipje

8th July 2016, 09:09

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

8th July 2016, 15:22

Yes.

note: you can build it by yourself.

Selur

15th July 2016, 17:34

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

17th July 2016, 23:09

Why is there no YUV 4:4:4 Encoder? :-(

umezawa_takeshi

20th July 2016, 16:31

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

20th July 2016, 17:31

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

20th July 2016, 23:04

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

3rd September 2016, 11:54

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

3rd September 2016, 21:45

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

3rd September 2016, 22:01

He said don`t send RGB to YUV codec :)

De-M-oN

3rd September 2016, 22:10

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

4th September 2016, 09:22

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

4th September 2016, 21:47

Okay. Thanks for clearing up.

Then I'm looking forward for this and so far: Thank you so much ♥

Sparktank

23rd October 2016, 04:43

What is the advantage of using QT

Anyone can answer this.

Some users switched to older versions to use QT.

LigH

23rd October 2016, 07:06

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

12th November 2016, 14:47

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

13th November 2016, 00:19

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

13th November 2016, 09:56

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

30th December 2016, 07:49

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

30th December 2016, 22:22

Thank you!

Taurus

31st December 2016, 23:14

Thank you!
And a Happy New Year!

umezawa_takeshi

3rd January 2017, 10:15

Ignus2

3rd January 2017, 11:17

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

3rd January 2017, 16:34

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

3rd January 2017, 16:53

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

5th January 2017, 16:45

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)