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

goemon

29th December 2017, 11:13

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

29th December 2017, 18:48

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

4th April 2018, 23:16

@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

4th April 2018, 23:56

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

5th April 2018, 00:03

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

5th April 2018, 02:17

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

5th April 2018, 02:33

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

5th April 2018, 04:28

... 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

5th April 2018, 07:02

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

5th April 2018, 07:35

.. 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

6th April 2018, 19:39

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

7th April 2018, 04:50

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

7th April 2018, 14:24

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

7th April 2018, 14:35

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

14th April 2018, 11:53

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

14th April 2018, 17:09

Arigato, umezawa_takeshi-sama.

umezawa_takeshi

18th April 2018, 15:59

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

19th April 2018, 08:14

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

19th April 2018, 14:24

LigH

19th April 2018, 18:55

:thanks:

Not your most active user, but a grateful one, nevertheless.

Emulgator

25th April 2018, 18:43

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

WorBry

26th April 2018, 04:13

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

4th June 2018, 17:04

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

21st July 2018, 20:03

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

13th January 2019, 17:02

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

11th March 2019, 20:00

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

11th March 2019, 23:52

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

12th March 2019, 00:02

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

12th March 2019, 00:36

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

12th March 2019, 00:38

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

12th March 2019, 15:41

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

12th March 2019, 16:08

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

12th March 2019, 19:20

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

12th March 2019, 20:24

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

13th March 2019, 01:29

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

13th March 2019, 02:20

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

15th March 2019, 15:04

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

15th March 2019, 15:21

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

16th March 2019, 22:19

@umezawa_takeshi
Thanks for the info.

mzso

19th March 2019, 16:59

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

19th March 2019, 18:02

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

19th March 2019, 18:03

umezawa_takeshi

20th March 2019, 17:49

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

23rd March 2019, 13:30

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

23rd March 2019, 17:08

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

24th March 2019, 09:35

mzso

24th March 2019, 12:19

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