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

Ignus2

6th January 2017, 17:51

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

6th January 2017, 18:34

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

6th January 2017, 18:51

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

7th January 2017, 01:01

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

7th January 2017, 15:54

Well, I'm 100% sure it wasn't on Windows :)
-f image2: same thing, believe me, I tried all possibilities :)

umezawa_takeshi

15th January 2017, 13:54

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

28th January 2017, 08:37

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

28th January 2017, 09:27

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

28th January 2017, 09:53

^ thank you LigH. I have Hcenc. Personally I feel CCE far outshines Hc.

kolak

28th January 2017, 15:05

Yep, specially for progressive sources. YUY2 is what you want to feed into CCE.

osgZach

29th January 2017, 22:28

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

30th January 2017, 15:17

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

31st January 2017, 03:44

Thank you for this information.

umezawa_takeshi

12th February 2017, 07:13

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

11th March 2017, 14:19

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

11th March 2017, 15:43

FFV1 is slow. It's about compression not speed.

umezawa_takeshi

11th March 2017, 15:50

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

11th March 2017, 16:07

FFV1 is slow. It's about compression not speed.

Come to think of it, that's right. hmm...

umezawa_takeshi

1st April 2017, 16:01

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

5th May 2017, 22:37

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

25th May 2017, 16:21

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

27th May 2017, 20:59

@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

27th May 2017, 21:10

Use OBS Studio (with your card) combined with NVEnc for the encoding.
near no FPS loss and you decide if lossless or lossy ;)

mariush

27th May 2017, 23:51

umezawa_takeshi

28th May 2017, 08:49

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

28th May 2017, 11:16

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

28th May 2017, 11:46

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

28th May 2017, 16:53

easy2Bcheesy

29th May 2017, 18:07

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

29th May 2017, 18:13

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

1st June 2017, 21:38

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

20th June 2017, 18:39

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

20th June 2017, 21:02

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

21st June 2017, 13:45

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

21st June 2017, 16:45

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

21st June 2017, 21:06

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

21st June 2017, 21:25

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

2nd July 2017, 11:47

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

16th July 2017, 09:01

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

19th July 2017, 05:48

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

19th July 2017, 06:37

yup

19th July 2017, 07:22

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

19th July 2017, 07:28

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

19th July 2017, 12:01

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

19th July 2017, 12:18

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.