Quick lossless codec comparison

2013-09-01 06:36:20 am

thethrillness.blogspot.com

I decided to see what the current state of lossless codecs were like. Most people including me usually recommend Lagarith but lets see if it actually is the best choice for capturing a speedrun.

With SD footage it doesn't really matter what codec you use since the resolution is small but in my opinion it is when you start to introduce 720p and 1080p that the codec choice becomes more important.

I am using AmarecTV 2.31 and a PS3 running the intro to MGS4 with HDMI at 720p. A 1 minute 30 second sample was recorded of the same scenes for each codec. It's a good blend between static, slow and fast movement to really test each codec.

So the codecs we are trying along with maximum bitrate and cpu usage achieved during testing are below. These were taken from Amarec's stats. The colorspace was YUY2. File sizes have also been included.

Ut Video ULH2 (4:2:2) - 51 Mb/s and 25% cpu max - 2.20gb
Ut Video ULH0 (4:2:0) - 40 Mb/s and 25% cpu max - 2.19gb
Lagarith (used multithreading) - 42 Mb/s and 43% cpu max - 1.85gb
Huffyuv - 55 Mb/s and 30% cpu max - 3.30gb
x264vfw (Convert to YUV 4:2:0) - 19 Mb/s and 7% cpu max - 850mb
x264vfw (Keep/Accept Only YUV 4:2:2) - 21 Mb/s and 7% cpu max - 975mb
x264vfw (Keep input colorspace) - 21 Mb/s and 7% cpu max - 950mb (seems identical to the keep/accept only option).

^ All x264vfw tests used the Ultra fast preset and obviously the single pass lossless mode.

Some observations:

1. ULH2 and ULH0 although have a significant bit rate difference in high motion the small 1:30 sample is not enough to show a filesize difference.
2. Lagarith takes too much CPU for my liking. Especially if you are considering streaming. ULH2 is a worthy replacement if you don't mind slightly higher filesizes.
3. Huffyuv is not even worth considering with those numbers. The file size is much larger because I noticed that even during static scenes Huffyuv will still require a high bitrate where some of the other codecs don't.
4. I honestly can't tell a visual difference between x264 even with Convert to YUV 4:2:0 and Lagarith in YUY2 mode but just for safety and an increase in 2Mb/s you may as well use keep input colorspace to retain 4:2:2.

I feel with these preliminary tests we should consider x264vfw a major candidate and recommendation over Lagarith. The massive reduction in bit rate and CPU usage is very attractive. What interested me was that with all 3 settings MediaInfo reported 4:2:0 subsampling which worried me but Yua reported yuv422p for both the keep/accept 422 and keep input colorspace option (it showed yuv420p for the convert 420 option as expected). Not sure what program to believe.

Feel free to do your own testing and report back!

Thread title:

I decided to see what the current state of lossless codecs were like. Most people including me usually recommend Lagarith but lets see if it actually is the best choice for capturing a speedrun.

With SD footage it doesn't really matter what codec you use since the resolution is small but in my opinion it is when you start to introduce 720p and 1080p that the codec choice becomes more important.

I am using AmarecTV 2.31 and a PS3 running the intro to MGS4 with HDMI at 720p. A 1 minute 30 second sample was recorded of the same scenes for each codec. It's a good blend between static, slow and fast movement to really test each codec.

So the codecs we are trying along with maximum bitrate and cpu usage achieved during testing are below. These were taken from Amarec's stats. The colorspace was YUY2. File sizes have also been included.

Ut Video ULH2 (4:2:2) - 51 Mb/s and 25% cpu max - 2.20gb
Ut Video ULH0 (4:2:0) - 40 Mb/s and 25% cpu max - 2.19gb
Lagarith (used multithreading) - 42 Mb/s and 43% cpu max - 1.85gb
Huffyuv - 55 Mb/s and 30% cpu max - 3.30gb
x264vfw (Convert to YUV 4:2:0) - 19 Mb/s and 7% cpu max - 850mb
x264vfw (Keep/Accept Only YUV 4:2:2) - 21 Mb/s and 7% cpu max - 975mb
x264vfw (Keep input colorspace) - 21 Mb/s and 7% cpu max - 950mb (seems identical to the keep/accept only option).

^ All x264vfw tests used the Ultra fast preset and obviously the single pass lossless mode.

Some observations:

1. ULH2 and ULH0 although have a significant bit rate difference in high motion the small 1:30 sample is not enough to show a filesize difference.
2. Lagarith takes too much CPU for my liking. Especially if you are considering streaming. ULH2 is a worthy replacement if you don't mind slightly higher filesizes.
3. Huffyuv is not even worth considering with those numbers. The file size is much larger because I noticed that even during static scenes Huffyuv will still require a high bitrate where some of the other codecs don't.
4. I honestly can't tell a visual difference between x264 even with Convert to YUV 4:2:0 and Lagarith in YUY2 mode but just for safety and an increase in 2Mb/s you may as well use keep input colorspace to retain 4:2:2.

I feel with these preliminary tests we should consider x264vfw a major candidate and recommendation over Lagarith. The massive reduction in bit rate and CPU usage is very attractive. What interested me was that with all 3 settings MediaInfo reported 4:2:0 subsampling which worried me but Yua reported yuv422p for both the keep/accept 422 and keep input colorspace option (it showed yuv420p for the convert 420 option as expected). Not sure what program to believe.

Feel free to do your own testing and report back!

nate

2013-09-01 09:23:03 am

seems like you came to the same conclusion i did about x264 taking over. this is partly why i made kumari record using it. but at my day job we are switching over to it too. we have to pay the license fee to sell products that include it but it's worth it when it wipes the floor with everything else.

not sure about the 4:2:2 versus 4:2:0 thing. maybe the game is being displayed in 4:2:0 originally and that's why you can't tell a difference? would also explain why the bitrate is less for 4:2:0 even though it shouldn't matter if it's 4:2:2 originally, at least from what i've read. maybe someone who knows more about hd can weigh in.

TheThrillness

2013-09-01 01:33:59 pm

thethrillness.blogspot.com

I know what was causing the MediaInfo thing.

In profile drop down of x264vfw you can select "High 4:2:2" which reports it properly in MediaInfo.

honorableJay

2013-09-01 03:38:43 pm

The Dork Knight himself.

Can you post comparison screenshots of the captures? I'm not the best with the newest tech, but how can you have a lossless video that is 1/2 the size of another lossless codec with 1/4 of the processing required and still have mathematically the same picture? It's not that I don't believe your results, I'm just wondering if this will cut out some of the finer details of the video.

blizzz

2013-09-01 03:51:44 pm

If it cuts out detail it's no longer lossless. I guess the best analogy is zip, 7z, rar, tar.gz etc. Those are also lossless and have different compression rates. I guess x264 is just extremely optimized.

TheThrillness

Edit history:

TheThrillness: 2013-09-02 06:18:53 am

TheThrillness: 2013-09-02 04:57:28 am

2013-09-02 04:46:53 am

thethrillness.blogspot.com

I used two screenshots from two different games this time. Both with cut scenes. I compared directly to Lagarith.

I ran PSNR and SSIM to check for any differences using MSU VQMT tool (You have to convert the PNG to BMP and select pro version to have HD calculation). Both metrics gave a 100% identification of being the same for each comparison. x264vfw is indeed identical to Lagarith for like half the bit rate (during intensive scenes) and 1/4 CPU usage (as indicated by Amarec). I might have to go into task manager and see what the real difference is.

Edit - I compared "Convert to 420" and it was not lossless but like 99.9% so yes for 100% lossless select "Keep input colorspace".

Edit 2 - I compared Task manager CPU usage with Lagarith and x264vfw. Lagarith actually has slightly less CPU load (about 5-6% lower) but Lagarith takes approximate double bit rate. Both never go over 30% in Task manager. Also just to see I checked Ut Video ULH2 and although it had the lowest CPU usage (never above 12%) its bit rate is higher than Lagarith.

Conclusion.... either Lagarith or x264vfw with "Keep input colorspace" is the best option.

It should be noted that 720p is on the threshold for Lagarith. Weeks agao I dropped frames if I used Lagarith at 1080p but x264vfw was fine. I guess to future proof myself I will move to x264vfw for everything. Heck if you have like an Ivy Bridge chip you could lower the preset in x264vfw and probably save another few Mb/s.

I used two screenshots from two different games this time. Both with cut scenes. I compared directly to Lagarith.

I ran PSNR and SSIM to check for any differences using MSU VQMT tool (You have to convert the PNG to BMP and select pro version to have HD calculation). Both metrics gave a 100% identification of being the same for each comparison. x264vfw is indeed identical to Lagarith for like half the bit rate (during intensive scenes) and 1/4 CPU usage (as indicated by Amarec). I might have to go into task manager and see what the real difference is.

Edit - I compared "Convert to 420" and it was not lossless but like 99.9% so yes for 100% lossless select "Keep input colorspace".

Edit 2 - I compared Task manager CPU usage with Lagarith and x264vfw. Lagarith actually has slightly less CPU load (about 5-6% lower) but Lagarith takes approximate double bit rate. Both never go over 30% in Task manager. Also just to see I checked Ut Video ULH2 and although it had the lowest CPU usage (never above 12%) its bit rate is higher than Lagarith.

Conclusion.... either Lagarith or x264vfw with "Keep input colorspace" is the best option.

It should be noted that 720p is on the threshold for Lagarith. Weeks agao I dropped frames if I used Lagarith at 1080p but x264vfw was fine. I guess to future proof myself I will move to x264vfw for everything. Heck if you have like an Ivy Bridge chip you could lower the preset in x264vfw and probably save another few Mb/s.

Attachment:

scrrenshotsx264vlagarith.rar

honorableJay

2013-09-02 06:39:42 am

The Dork Knight himself.

Nice, looks like I'll have to make the switch too. How do I get Amarec to use x264vfw anyway?

TheThrillness

Edit history:

TheThrillness: 2013-09-02 07:02:14 am

2013-09-02 06:59:59 am

thethrillness.blogspot.com

You just select it like you would Lagarith in Amarec: http://sourceforge.net/projects/x264vfw/

Set it up like this. Note that if you set the profile to High 4:2:2 it won't work in Amarec when you press record but since the resulting file is lossless anyway it's fine.

Attachment:

x264vfw1.png

honorableJay

2013-09-02 10:53:14 am

The Dork Knight himself.

Ah, thx. I thought it was already part of ffdshow or some other codec pack that I didn't have. I'll have to test this with my PC games to see how it compares against Fraps. I know the files will be of higher quality than Fraps, but I'm interested in this for the filesize. Time to record some Batman Smiley

TheThrillness

Edit history:

TheThrillness: 2013-09-02 11:16:30 am

2013-09-02 11:15:36 am

thethrillness.blogspot.com

Quote from honorableJay:

I know the files will be of higher quality than Fraps, but I'm interested in this for the filesize. Time to record some Batman Smiley

You got me thinking.

I set a QP of 16 which should be visually lossless to the human eye. Amarec bitrate never went over 7Mb/s.... and I got 99.7% simialrity on SSIM to Lossless and CPU usage is actually less than lossless (by 1-2%).

A 1 minute and 6 seconds of video was 291mb at 720p which is pretty much lossless to the human eye. Absolutely ridiculous.

blizzz

Edit history:

blizzz: 2013-09-02 04:44:52 pm

2013-09-02 11:34:49 am

Just remember that you'll most likely reencode the files for storage or release to get better compression. 16 should be fine for most cases (that's basically BluRay quality, just not as efficiently compressed), but the errors will multiply and a lossy raw will lead to a bigger final encode. Unless you're really low on disk space I would just stick with lossless, or a quantizer below 10.

nate

2013-09-02 03:55:48 pm

what's the difference in file size between quantizer 0 (lossless) and quantizer 1?

honorableJay

Edit history:

honorableJay: 2013-09-02 03:57:34 pm

2013-09-02 03:56:03 pm

The Dork Knight himself.

Interestingly enough, I'm getting quite different results recording the intro movie to Arkham Asylum at 720p (PC version). I setup x264vfw as you said, ultrafast singlepass lossless, and compared the same 1:30 intro clip between x264, Fraps, and Lagarith to see what the final file sizes would be.

Fraps: 1.03GB
Lags: 1.33GB
x264vfw: 1.83GB

Fraps I can understand coming in at the lowest since it does some minor compression, but the fact that Lags turned in a 500MB smaller file than x264 is having me scratch my head. Are you sure that you used the lossless mode for x264 when you recorded the intro movie? Why would my setup turn out the exact opposite results? Would it be that I'm recording RGB instead of YUV? If that's the case I may have to stick with Lags since I can't record PC games in YUV.

TheThrillness

Edit history:

TheThrillness: 2013-09-02 05:02:33 pm

2013-09-02 05:01:23 pm

thethrillness.blogspot.com

That definitely is weird. I can only guess it is the RGB issue as you mentioned.

Just to verify can you try some YUY2 source video with x264vfw?

honorableJay

Edit history:

honorableJay: 2013-09-02 06:15:19 pm

honorableJay: 2013-09-02 05:14:39 pm

2013-09-02 05:13:51 pm

The Dork Knight himself.

That's the problem, aside from my genesis the only other footage I can record is PC content. Right now I'm using SCFH to grab the game window and feed it into Amarec for recording, and SCFH only sends in RGB. If you know of a way (without using Dxtory, don't have the money for another recording program) to capture PC games in YUY2 (without telling the codec to change the colorspace) I'm all ears.

**Edit**
Ok, so a quick test with some Genesis footage shows similar results to yours, but not as drastic. A 25 second clip of the intro to Batman Returns came up as 128MB with Lagarith (YUY2) while x264vfw (keep colorspace, which is YUY2 from my Dazzle) was 109MB. So it looks like for RGB sources Lagarith is gonna trump x264vfw BUT YUY2 overall x264vfw is the better option.

Omnigamer

Edit history:

Omnigamer: 2013-09-02 06:24:24 pm

Omnigamer: 2013-09-02 06:21:57 pm

2013-09-02 06:21:40 pm

All the things

These tests have been done in a larger, objective manner here. The results are all from 2007, but I don't think the specifications for any of the target codecs has been changed since then. Thankfully this is one of the free reports; newer reports are $700 or more. Other possible differences from now may be from instruction set accelerators for one codec or another.

TheThrillness

2013-09-02 07:06:02 pm

thethrillness.blogspot.com

Quote from honorableJay:

**Edit**
Ok, so a quick test with some Genesis footage shows similar results to yours, but not as drastic. A 25 second clip of the intro to Batman Returns came up as 128MB with Lagarith (YUY2) while x264vfw (keep colorspace, which is YUY2 from my Dazzle) was 109MB. So it looks like for RGB sources Lagarith is gonna trump x264vfw BUT YUY2 overall x264vfw is the better option.

Yes it seems like the higher the resolution you go the more x264vfw pulls ahead. It should only really be considered for 720p and plus.

nate

2013-09-02 07:07:45 pm

Quote from Omnigamer:

These tests have been done in a larger, objective manner here. The results are all from 2007, but I don't think the specifications for any of the target codecs has been changed since then. Thankfully this is one of the free reports; newer reports are $700 or more. Other possible differences from now may be from instruction set accelerators for one codec or another.

the specifications haven't changed but x264 has seen substantial improvements. for reference, sda adopted h.264 in summer 2006, and there was a lot of complaining because it was so new and poorly supported. i was surprised to learn that x264's lossless mode even existed in 2007. the tests people are doing in this thread will probably prove more insightful than that document.

TheThrillness

2013-09-03 06:46:52 am

thethrillness.blogspot.com

Jay, this probably won't do anything but worth a try. Can you select "Keep/Accept only YUV 4:4:4" instead of "Keep input colorspace" and see if that improves the filesize or even works at all?

honorableJay

Edit history:

honorableJay: 2013-09-04 09:51:40 pm

2013-09-03 07:10:22 am

The Dork Knight himself.

Sure, I'll test it when I get home from work.

**Edit**
Ok, so I tried to record in YUY2, and basically it was a bust. Since SCFH ONLY captures in RGB, if I tried to setup amarec to grab the video feed with YUY2 instead of RGB it defaulted to the first valid entry for the "video device" which was 320x240 RGB. The other option (keep/accept only YUV 4:4:4) resulted in a failure to begin capturing. Apparently x264vfw has no way to convert the colorspace to YUY2 from RGB unless I use the "Convert to YUV 4:2:0" which I really don't want to do since it'll lose a lot of the detail and will probably destroy the source footage.

blizzz

2013-09-05 02:09:23 am

--input-csp rgb --output-csp i422 might work.

honorableJay

2013-09-10 03:40:12 pm

The Dork Knight himself.

Well I might have to hold off on using x264 for lossless for a while. I'm not sure what's causing it, but all of my recordings have the audio 3 frames ahead of the video. Granted it's not the worst to fix, but still annoying to deal with.

TheThrillness

Edit history:

TheThrillness: 2013-09-10 03:58:21 pm

2013-09-10 03:53:29 pm

thethrillness.blogspot.com

This option says it will hurt compression efficiency but might be useful still. Try ticking "Zero Latency" in the encoder settings (just bottom left of Keep input colorspace). I'd prefer that not to be the solution because then the data rate might become similar to Lagarith then we are back at square 1.

Maybe try ticking/unticking "Match the start timing of the audio with a video" in Amarec's Advanced tab?

bytesaber

2017-03-13 03:52:00 pm

Is the advise to use x264vfw this way, still relevant as a current approach to lossless YUY2 capture for today?

Omnigamer

2017-03-13 06:00:18 pm

All the things

It is still perfectly applicable, yes. There are more alternatives now, but x264vfw will still give good performance and filesize for most recording purposes. I recommend also using the fast decode and zero latency options to help with editing files and ensure the audio lines up.