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

[Emulgator]

10 Years ! Congratulations & many thanks !
Time for a donation !
Done.

[WorBry]

Originally Posted by Emulgator

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 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) / readme / Windows (exe) / source code / GitHub

[umezawa_takeshi]

Version 20.2.0 is released.

Performance Improvements

• ULxx: Speed up encoding on x64.

License (GPLv2) / readme / Windows (exe) / source code / GitHub

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

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%

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

Originally Posted by 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.

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]

Originally Posted by mzso

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]

Originally Posted by poisondeathray

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.

Originally Posted by poisondeathray

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]

Originally Posted by mzso

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

Originally Posted by mzso

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]

Originally Posted by poisondeathray

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.

Originally Posted by poisondeathray

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]

Originally Posted by mzso

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 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) / readme / Windows (exe) / source code / GitHub

[umezawa_takeshi]

Originally Posted by mzso

Is there an ecoding guide around?

Currently, no.

Originally Posted by mzso

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.

Originally Posted by mzso

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.

Originally Posted by mzso

Is the "pro" codec only different in encoding in higher bit depth?

"Pro" variants support higher bit depth and less functionality.

Originally Posted by mzso

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?) ?