x264 Lossless vs UtVideo: comparison of compression & speed performance

[kypec]

I did few tests while looking for suitable lossless video codec. I needed intermediate storage due to quite demanding AVS processing and targeting 2-pass encode - see my script below:# Initialize variable with path to my A/V tools
global avdir="C:\Program Files (x86)\AVTools\"
# Load all the plugins that will be used in the script
LoadPlugin(avdir + "dgmpgdec\DGDecode.dll")
LoadPlugin(avdir + "plugins\mvtools2.dll")
LoadPlugin(avdir + "plugins\mt_masktools-25.dll")
LoadPlugin(avdir + "plugins\nnedi3.dll")
LoadPlugin(avdir + "plugins\RepairSSE2.dll") # Repair (v1.0PR)
LoadPlugin(avdir + "plugins\RemoveGrainSSE2.dll") # RemoveGrain (v1.0PR)
LoadPlugin(avdir + "plugins\FFT3DFilter.dll")
LoadCPlugin(avdir + "plugins\yadif.dll") # Yadif (v1.7)

Import(avdir + "plugins\QTGMC2.51.avsi")
# Preset : Choose from "Placebo","Very Slow","Slower","Slow","Medium","Fast","Faster","Very Fast","Super Fast","Ultra Fast" & "Draft". Default = "Slower"
# Tuning : Choose from "None", "DV-SD", "DV-HD". Default = "None".
# Presets "Super Fast"/"Ultra Fast" & EdiMode="TDIYadif"/"Yadif" require the Yadif plugin, which doesn't autoload. Typically the calling script would load it.

# Open source video clip
MPEG2Source("01.d2v",info=3,cpu=4)
# Deinterlace, QTGMC outputs smoother doubled framerate from interlaced input
QTGMC(Preset="Fast",Tuning="DV-SD",NoiseBypass=1,NoiseRemove=1.0,NoiseRestore=0.25).SelectEven()
# Select 60s = 12 sequences in total with 5s duration each
SelectRangeEvery(FrameCount/12, Round(FrameRate*5), 400)
ConvertToYV12(interlaced=false)
Raw Avisynth outputs @ 6.27 FPS (890MB).
My first attempt was Ut Video 8.5.0 (http://forum.doom9.org/showthread.php?t=143624). Speed of encoding via avs2avi was quite impressive @ 6.20 FPS (348MB) despite having the codec configured for high compression and not speed.
Final x264 encode {r1804 x64 --preset slow} finished @ 80.46 FPS [1st pass] + 26.08 FPS [2nd pass].
Then I tried lossless mode of x264 {--qp 0 --preset fast output.mkv}.
Encoding speed was slightly worse @ 5.80 FPS ~ 6% slower than UtVideo, but the compression ratio improved considerably (195MB) ~ 56% of UtVideo filesize.:cool:
Final encode with same settings finished @ 45.87 FPS [1st pass] + 22.46 FPS [2nd pass]. Except the relatively much slower first pass I decided to go with x264 Lossless for my purposes - space savings are more important to me and given that all of the above tests were performed on Intel E8400/4GB RAM/Win7 x64 (dual core only without HT) I believe running real world encodes on my home i7-920 (quad core with HT) will provide even better speeds compared to UtVideo.
BTW Have any of you an idea how well is UtVideo multithreaded?

[Dark Shikari]

If you want to improve decoding speed, use --tune fastdecode with your lossless encode.

[Didée]

Just for fun, repeat the test with a plain "Yadif()" instead of QTGMC. One of the (intended) effects of Q/TGMC is that the result is particularly compression-friendly. It would be interesting to see how much worse the compression ratio is when a "simple" deinterlacer is used. (And moreover, not to create a false myth "x264 lossless compresses almost 2 times as strong as UT video" -- most probably, that's not generally true.)

[JEEB]

Let's just say that you're comparing apples to oranges here, too.

UT Video is mainly for quick capture and editing after that (hint: realtime 720p game capture from a card at a relatively high frame rate, and then mixing and matching the output with various NLE apps for blue/greenscreen etc.). So it as a format has been designed so that it has very fast encoding speed together with seeking speed, at the expence of compression. You can get similar results from x264 by using a very, very short keyint (such as --keyint 3 or less) together with fastdecode.

X264's lossless can be quite fast to decode and encode in your case, but A) I'm not sure if you can really pull off as much as speed off it as with UT Video and B) By default the keyint will be rather long, which will go against the "fast to seek" objective of UT Video.

If your usage is just to output your script at the speed of the script (~5-6fps) to a file that decodes quickly from start to finish without much seeking, yes -- then, of course, x264's lossless is the better solution as it gives out good compression with quite fast decoding speed if no seeks are done in between of the IDR frames.

TL;DR
Completely differently designed codecs give different results. Surprised much?

[Dark Shikari]

If you care about seeking, you can use a short keyframe interval in x264; it won't hurt things much unless it's really short, like 2 or something.

[kypec]

DS, thanks for --tune fastdecode tip, it has definitely improved the speed for final encode @ 75.71 + 25.39 FPS, so basically it is on par with Ut Video now. Compression is worse, obviously, (222MB > 195MB) but it is still only ~ 64% of Ut Video.

Didée, I did the Yadif tests, just for fun as you suggested because once I saw your video where different deinterlacers were compared I decided to try this QTGMC. Previously, I was using Yadif for all my encodes and thought how good and fast it is. Well, it certainly is fast, but looking at its output side by side with what QTGMC produces I feel terribly ashamed how I could accept such awful quality before.:o
As for the compressibility, Ut Video performed equally well for the filesize (348MB) yet speed was MUCH better @ 80.98 FPS :)
Lossless x264 OTOH suffered a bit on the compression (233MB) which is ~5% more than QTGMC denoised source. However, the speed was not that amazing @ 30.30 FPS, despite the --tune fastdecode option used.

JEEB, ability to seek is absolutely unimportant factor here. I intend to use lossless video files just as the intermediate sources for final x264 encoding. Thanks for pointing it out though, perhaps others might find it important for their purposes. Given that Lossless x264 performs almost as fast as Ut Video (5.97 < 6.20 FPS) and compresses my footage much better I'll go with it!:p

[JEEB]

JEEB, ability to seek is absolutely unimportant factor here. I intend to use lossless video files just as the intermediate sources for final x264 encoding. Thanks for pointing it out though, perhaps others might find it important for their purposes. Given that Lossless x264 performs almost as fast as Ut Video (5.97 < 6.20 FPS) and compresses my footage much better I'll go with it!:p

Yes, I understand. And in your case the selection is completely correct. As I already pointed out.

I'm just herping a derp because UT Video was, after all, done for very fast encoding and decoding as well as seeking to begin with (NLE usage and real-time capture). And you were testing it for compression and decoding speed, forgetting the fact that if we could have a codec that could do all of this in one mode we would already be using it :V. Or then you didn't read about UT Video at all. This is like comparing Huffyuv to x264's lossless. The result is already guessable, very much so.

DeathWolf made a real lossless codec comparison IIRC, too bad A) he never updated it with UT Video so that x264 was there and B) that it's no longer up.

Edit: Also, your thread's title makes it apparent that you'd be making an overall comparison -- which you definitely are not.

[kypec]

JEEB, I'm truly sorry if you feel like I'm defaming UtVideo codec or anything like that. Why that attacking tone? It isn't and never was my intention.
I was just evaluating the possibilities with the tools freely available and trying to find the one most suitable for my purposes. I never said that Ut Video is bad codec, no. It is good codec and certainly has some nice advantages, like speed for instance.
What is wrong about presenting personal opinion on preferred features that one's looking in certain software? I did precisely that - stated my test results and explained why picked one product over another.
Perhaps my findings will help another user who is looking for similar tool suitable for same purpose, who knows? I surely would be glad if there were the tests like this publicly available somewhere.
I changed the thread title to be more specific so hopefully you won't be objecting anymore.:helpful:

[mp3dom]

Intermediate lossless codecs as UTVideo (but also Canopus Lossless, HuffYUV, Lagarith etc.) are useful for post-production work and to keep 'tapeless' master. The advantages are the facts that supports all major colorspaces (RGB/YUY2/YV12). In postproduction, working with YV12 is really bad since it loose a lot of informations, can have problems with interlaced contents and is not suitable for chroma keying. Codecs like UTVideo allows to edit like an uncompressed source but with reduced filesize. Also, if you need to do a tapeless master, there's no reason to convert it to YV12 because you don't know in the future what work you will need to do. Most of the times the tapeless master is at least in YUY2 colorspace.
If you're using an intermediate file only for an encoding process, you can use whatever you want that have enough speed that allows you to avoid decoding bottleneck.

[JEEB]

JEEB, I'm truly sorry if you feel like I'm defaming UtVideo codec or anything like that. Why that attacking tone? It isn't and never was my intention.
I was just evaluating the possibilities with the tools freely available and trying to find the one most suitable for my purposes. I never said that Ut Video is bad codec, no. It is good codec and certainly has some nice advantages, like speed for instance.
What is wrong about presenting personal opinion on preferred features that one's looking in certain software? I did precisely that - stated my test results and explained why picked one product over another.
Perhaps my findings will help another user who is looking for similar tool suitable for same purpose, who knows? I surely would be glad if there were the tests like this publicly available somewhere.
I changed the thread title to be more specific so hopefully you won't be objecting anymore.:helpful:

I am not really an avid supporter of the given codec (I do like it for RGB, RGB with Alpha and similar non-YV12 colorspaces though), but I just saw the 'way' you tested the codecs and I couldn't keep my mouth shut. Although I don't think I'm attacking you, I'm just trying to make you understand how futile your effort was and that it isn't really positive that you're trying to market it as an overall benchmark between these two codecs.

I was just evaluating the possibilities with the tools freely available and trying to find the one most suitable for my purposes.
This you, indeed, did. It basically shows that when you need to encode something that's not bottlenecked on the encoder to around 5-6fps and are looking for decode speed from A to Z without further seeking and you're looking for the maximum compression, x264 is better. This A) isn't surprising and B) applies only to your case.

What is wrong about presenting personal opinion on preferred features that one's looking in certain software? I did precisely that - stated my test results and explained why picked one product over another.
Perhaps my findings will help another user who is looking for similar tool suitable for same purpose, who knows? I surely would be glad if there were the tests like this publicly available somewhere.
Nothing wrong with testing, but this is a very limited test, which only tells us something we already know by the overall design features of these codecs.

And now, let's look at some other tests done on the internets. They do miss some stuff like exact settings used for every codec and the explicit versions used, as well as the clips -- but I think you will get my point after passing your eyes through these. These are the old DeathWolf's lossless tests that are apparently now offline if not for a certain kind soul who pastebin'd two of them:

Bored lossless encoding test
YV12 848x480@23.976, source on ramdisk, x264 is in lossless mode, destination null

Encode Test, sorted by size
===========================
Codec FPS Size(MB) Comment
X264 58.26 180.81 (multi threaded,default)
X264 16.98 180.81 (mono threaded,default)
X264 65.24 182.40 (multi threaded,fast)
X264 18.74 182.40 (mono threaded,fast)
X264 486.81 234.41 (multi threaded,ultrafast)
X264 155.42 234.41 (mono threaded,ultrafast)
X264 147.47 284.27 (mono threaded,ultrafast, -I 3)
FFV1 54.90 289.07 (default, yv12 colorspace)
X264 145.77 306.96 (mono threaded,ultrafast, -I 2)
Lagarith 110.51 340.63 ()
FFHuffYV12 287.33 383.39 (default, yv12 colorspace)
X264 136.96 390.37 (mono threaded,ultrafast,all intra)
HuffYV12 615.80 443.91 ()
VBLE 261.22 458.22 ()
Null Codec 1724.4 1274.9 ()


Decode Test, sorted by speed
============================
Codec FPS Comment
FFV1 42.46 (default, yv12 colorspace)
VBLE 46.34 ()
Huffyv12 86.20 ()
Lagarith 88.86 (yv12 mode)
FFMS2 X264 99.78 (default)
FFMS2 X264 100.23 (fast)
FFMS2 X264 159.63 (ultrafast,all intra, much faster seeking)
FFMS2 X264 187.40 (ultrafast,-I 2, faster seeking)
FFMS2 X264 195.92 (ultrafast,-I 3, fast seeking)
FFHuffYV12 221.03 (default, yv12 colorspace)
FFMS2 X264 222.09 (ultrafast)
Null Codec 1725.8 ()I changed the thread title to be more specific so hopefully you won't be objecting anymore.

Note: please note that h264 is slow to seek:) so if you intend to browse around the stream, either fixing stuff/looking for stuff, it's not an ideal choice



Bored lossless encoding test V2
YV12 960x540@23.976, source on ramdisk, x264 is in lossless mode, 6000 frames

Encode Test, sorted by speed
===========================
Codec FPS Size(MB) Comment
FFV1 39.02 985.24 (default)
Lagarith 72.73 1166.94 ()
VBLE 233.22 1292.13 ()
FFHuffYV12 292.68 1196.25 (default, yv12 colorspace)
HuffYV12 521.74 1412.96 ()
Ut Video 420 727.36 1340.66 ()
Ut Video 420 774.29 1199.44 (predict median)
Null Codec 2181.8 4449.46 ()


Decode Test, sorted by speed
============================
Codec FPS Comment
FFV1 29.74 (default)
VBLE 35.66 ()
Huffyv12 69.97 ()
Lagarith 72.73 (yv12 mode)
FFHuffYV12 173.91 (default, yv12 colorspace)
Ut Video 420 399.39 (predict median)
Ut Video 420 523.95 ()


This is more useful than what you have done. The loading speed isn't limited (y4m from a RAM disk), and there otherwise aren't any apparent bottlenecks other than the encoder itself. You can see that this test, as well, brings to us the knowledge that x264's lossless compresses very, very good, as well as shows the true speed capabilities of UT Video. Of course, the file sizes will end up somewhat different per the type of source (these IIRC were animation sources), and to get better readings of speed we would have to run multiple passes, but this already shows us some data about x264 as well as several encoders usable in, f.ex. ffdshow's VFW encoder as well as Lagarith, Huffyv12 and UT Video.

I changed the thread title to be more specific so hopefully you won't be objecting anymore.
TL;DR Your test skews the numbers (the actual difference in speed between x264 and UT Video), which makes this just a compressibility test, nothing else. And yeah, you completely miss the point of actually telling the possible user, looking for benchmark results, the big differences between these two codecs (the 'differences of design'). Thank you very much.

[Didée]

Well ... I'll eat my hat that this test was done on animation, with quite a few of perfect dup frames.

x264-lossless achieving a >200% compression ratio compared to Huffyuv(yv12,median) ?? No way. Not in the real world.


Mini-test on 5000 frames of a natural film source (720x576 PAL) with film grain:

codec - enc time - file size

ffVH: 17 s - 1'054'851 kB

ffV1: 103 s - 908'379 kB

x264: 129 s - 927'552 kB

So much for the myth about "extraordinary compression" of x264-lossless. Perhaps on "special" content. But never-ever "generally". No way.

x264 is a great encoder, but it can't change the rules of entropy.

[JEEB]

Well ... I'll eat my hat that this test was done on animation, with quite a few of perfect dup frames.
Yes, most probably. Which I mentioned, I guess I should've removed the word 'somewhat' from the sentence in the part after the copypasta (about filesize changes etc.).

So much for the myth about "extraordinary compression" of x264-lossless. Perhaps on "special" content. But never-ever "generally". No way.

x264 is a great encoder, but it can't change the rules of entropy.
Yes, and I apologize if I made my text seem like that. I was only trying to make someone understand the problematic points of their "test" :)

[Dark Shikari]

Well ... I'll eat my hat that this test was done on animation, with quite a few of perfect dup frames. Likely not perfect dupe frames; even animation has noise. But of course this is obvious: on anything with significant noise, you'll basically never get over 3 to 1 compression.

[jmac698]

I did a big comparison as well, fully documented with settings and speed, but for slightly different purposes. I was only interested in real-time capture of SD on my machine.
http://forum.doom9.org/showthread.php?t=158420