Codecs to use with DxTory

[Malix]

Let's make a tread of good codecs to use with DxTory, list their strenghts and weaknesses.

Lagarith http://lags.leetcode.net/codec.html
+ Fast, supports multithreading, available in 32 and 64 bits
+ pretty good compression level most of the time, but INSANELY GOOD for retro/nes/old dos games
- may have stutter on lower end machines as the compression may cause a bit of overhead
- "Windows only", but kind-of supported by libavcodec for instance.

Ut Video Codec http://umezawa.dyndns.info/wordpress/?cat=28
+ Fast (especially YUV422-mode), supports multithreading, available in 32 and 64 bits
+ Codec available for Windows and Mac
+ less overhead than Lagarith (better performance on lower end machines)
- somewhat worse compression ratio than Lagarith
- Not very efficient with retro games if compared to Lagarith.

MagicYUV http://magicyuv.com/index.php/ (added 12.12.2014)
+ Seems to be faster than Lagarith and Ut Video Codec
- Apparently only available on Windows
- Crashes Nestopia when attempting recording with DxTory (atleast on my computer, other codecs work fine).


Personally, I use UtCodec MagicYUV for ~99% of my recordings since it seems to work faster during capture and editing for me, but your mileage may vary. For DOS/NES/etc retro games I'd suggest ALWAYS using Lagarith, it is unbeatable with those anyway you compare it.

So, you guys use other codecs worth mentioning?

edit:
removed false claim that Ut Video Codec had lossy mode too.

edit: Added MagicYUV, thanks De-m-on!

[ShamisOMally]

MasterNobodies x264 codec http://www.free-codecs.com/download/x264_VfW.htm (Top one on download page, 32-bit version)

+Incredibly low overhead
+Incredibly high compression
+Insanely high quality
+incredibly low filesize, 24-28gigs a hour of 1080p video at 55kbit is 99.999999999999999% lossless quality setting vs 310-350gigs a hour for FRAPS or 260-290gigs a hour lagarith lossless
-For 100% lossless (Bitrate of 80,000) jumps up to 40gigs a hour, which results in slow playback, most media players can't handle the decompression stream at 80kbit, causing video playback to be incredibly slow, even if all data is there when doing final encodes
-Compression is incredibly hard for most video editors to handle, like sony vegas, due to them having a low buffer space, causing slow playback while editing, even though final encode is flawless
-Does impact framerates a small or large bit depending on the games, which is the price you pay for getting filesizes 1/10th the size of the other codecs. Still incredibly low CPU use, but it does impact framerates slightly, or a lot depending on the game.

LAME ACM 3.99.5 http://www.free-codecs.com/download/lame_acm_codec.htm

+Incredibly small filesize
+Near lossless audio capture at 192kbit
-only captures in Stereo

*Update* New Codec I am using, full hardware GPU encoding for AMD cards only ATM, but info is here http://forum.exkode.com/index.php?topic=640.0

[Malix]

LAME ACM 3.99.5 http://www.free-codecs.com/download/lame_acm_codec.htm
+Lossless audio capture at 192kbit

FYI, mp3 is never lossless. At high bitrates it is really close, but never lossless. Same applies to your x264, if you specify bitrate, it is not lossless. Also I think you mixed up kbps and Mbps. 55kbps video will look like ye oldé RealMedia files from 90's.

[ShamisOMally]

*laughs*

Ok, I knew this was going to happen, I was going to mention both codecs, and somebody would get into a pissing match over them.

Protip: Even your "Lossless" codecs are also not lossless, they also miss stuff. They just capture as close as possible

And you can do that with x264 as well just by upping the bitrate through the roof, 80kbit is more data then 300kbit FRAPS/Lagarith is being captured, plus it scales

I was being polite and didn't criticize your codecs, did you want me to get into a pissing match and start doing that?

[Malix]

I'm sorry? Was something I said not true? Didn't mean it as a personal attack (edit: or attack at all), if that's how you took it o_O

Also, lossless is lossless, hence the mad bitrates. Colorspace conversions might cause some information to be lost, but RGB->RGB (for example) doesn't lose anything.

If I had some points wrong with Lagarith/Ut Video Codec, do point them out. This thread might actually be usefull to someone if we kept facts straight here.

[ShamisOMally]

No video capture is ever "Lossless", there is simply too much data on screen to be recorded pixel perfectly

It all comes down to "What space/resources do I want to sacrifice for a quality level I want" thing

55kbit with x264 is like 99.99% lossless, only some banding sometimes for large area's of dark colors, which is something all codecs struggle on, but you can get the same level of "Lossless" as Fraps/Lagarith by using a setting of 80-85kbit for a tenth the filesize, but again, most media players can't handle decompressing a stream like that on the fly

[Malix]

I'd still argue that lossless capture is indeed possible, depends entirely on recording resolution, fps, codec and underlying hardware (cpu, storage media). Of course I can't be sure wether or not fraps (the application, not the codec) or dxtory makes some colorspace alterations before passing the imagedata to codec. But the UT Video (RGB, ARGB modes) and Lagarith (RGB) can do lossless compression in realtime with modern hardware just fine.

Fraps codec by default is lossy, no arguments there. If you use it in RGB-mode, it is (afaik) lossless and so is Lagarith. Lagarith and UT Video Codec on my computer can encode 1080p roughly ~100-300fps speed, depending on the content of the material at hand but ofc. my storage can't keep up with that. That is why but I use merely 30fps for capture.

Losslessness can be easily tested: create a video -> encode with lossless codec -> re-encode the previously encoded video n-times with lossless codec -> if after nth iteration the starting video & last video are identical if you didn't alter colorspaces. I can do this later on if you wish.

Also, I also think you mean 55000kbit/s with that 55kbit, as x264 states:

Code Select Expand

Ratecontrol:
  -B, --bitrate <integer>     Set bitrate (kbit/s)
if you specify 55000 to that, it is 55Mbps / 55000kbps. But thats just me splitting hairs & being nitpicky with units.

[SirCrest]

No video capture is ever "Lossless", there is simply too much data on screen to be recorded pixel perfectly

It all comes down to "What space/resources do I want to sacrifice for a quality level I want" thing

55kbit with x264 is like 99.99% lossless, only some banding sometimes for large area's of dark colors, which is something all codecs struggle on, but you can get the same level of "Lossless" as Fraps/Lagarith by using a setting of 80-85kbit for a tenth the filesize, but again, most media players can't handle decompressing a stream like that on the fly

You're confusing lossless and raw.

Lossless means that outside of conversions, the input and output are identical. You can encode a video 5,000 times with a lossless codec and it will be identical. Do that with any lossy codec and the image quality will decline, no matter your bitrate.

Also your numbers are signicantly off. 55kbps is around dialup speed. You could manage video on 55kbps at maybe 120x80pixels. But try 1000 times that for high quality video recording. About 50Mbps would be a good place for an alternative to lossless recording for PC gaming for later editing and processing.

[ShamisOMally]

No video capture is ever "Lossless", there is simply too much data on screen to be recorded pixel perfectly

It all comes down to "What space/resources do I want to sacrifice for a quality level I want" thing

55kbit with x264 is like 99.99% lossless, only some banding sometimes for large area's of dark colors, which is something all codecs struggle on, but you can get the same level of "Lossless" as Fraps/Lagarith by using a setting of 80-85kbit for a tenth the filesize, but again, most media players can't handle decompressing a stream like that on the fly

You're confusing lossless and raw.

Lossless means that outside of conversions, the input and output are identical. You can encode a video 5,000 times with a lossless codec and it will be identical. Do that with any lossy codec and the image quality will decline, no matter your bitrate.

Also your numbers are signicantly off. 55kbps is around dialup speed. You could manage video on 55kbps at maybe 120x80pixels. But try 1000 times that for high quality video recording. About 50Mbps would be a good place for an alternative to lossless recording for PC gaming for later editing and processing.

Video bitrate is measured in Kbit not KByte

[Malix]

Video bitrate is measured in Kbit not KByte

kind of right, but not quite. He used kbps (or kbit/s, kb/s), which is kilobits per second, which is the most common unit for videobitrates, but when talking about really high bitrates it is easier to use Mbps so we wouldn't need to type so many zeroes or just to round it to closest meaningful unit (55000kbps = 55Mbps). Also, I can't see why we couldn't use kBps for video bitrates (as 1 byte is 8 bits, but I guess we all already knew that).
His units are correct and he did not use "KBytes" anywhere. Also, nitpicking that the k is lowercase (https://en.wikipedia.org/wiki/Metric_prefix)

[ShamisOMally]

Video bitrate is measured in Kbit not KByte

kind of right, but not quite. He used kbps (or kbit/s, kb/s), which is kilobits per second, which is the most common unit for videobitrates, but when talking about really high bitrates it is easier to use Mbps so we wouldn't need to type so many zeroes or just to round it to closest meaningful unit (55000kbps = 55Mbps). Also, I can't see why we couldn't use kBps for video bitrates (as 1 byte is 8 bits, but I guess we all already knew that).
His units are correct and he did not use "KBytes" anywhere. Also, nitpicking that the k is lowercase (https://en.wikipedia.org/wiki/Metric_prefix)

I was the one that used kbit correctly, he was saying I was saying kByte

I used lowercase b, not uppercase

Typically we only start measureing in Mb per second when we climb over 10Kbit, but my 55kbit remark was still not wrong, you can call it 5.5mbit if you want, you just move one decimal space

[Malix]

I was the one that used kbit correctly, he was saying I was saying kByte

I used lowercase b, not uppercase

Typically we only start measureing in Mb per second when we climb over 10Kbit, but my 55kbit remark was still not wrong, you can call it 5.5mbit if you want, you just move one decimal space

Except that there are no mentions of kbytes, kB or such before you brought it up.

Also, 1000k = 1M, so 55kbit = 0.055Mbit. To reiterate: the difference is 1000 fold, not 10.

The thing which makes you insist on 55kbps video being "almost lossless" might be the presentation of the number in x264 UI, the 55,000 and 80,000 figures you mentioned earlier actually presetn 55Mbps and 80Mbps respectively, the comma is thousands separator not a decimal point.

edit: math to back it up.
And I quote:

-For 100% lossless (Bitrate of 80,000) jumps up to 40gigs a hour

80 000kbps / 8 = 10 000kB/s
10 000kB/s * 3600s = 36 000 000kB ~= 36GB (roughly), which is nicely in the ballpark of the given 40GB.

[ShamisOMally]

80 000kbps / 8 = 10 000kB/s
10 000kB/s * 3600s = 36 000 000kB ~= 36GB (roughly), which is nicely in the ballpark of the given 40GB.

x264 encoding allocates bits depending on the complexity of a scene, my 55kbit setting I use and I play say TF2, I can capture at around 22-24gigs a hour, but something like fallout 3 will jump up to 26-29gigs a hour due to all the dark scenes etc (Dark being a color which requires more bitrate due to dark lumen values and how 4:4:4 and 4:2:0 works)

80kbit is more around 300-350kbit FRAPS/Lagloss for quality overall, but I don't know how to play it back at full speed as decompressing that high a bitrate into the pipe always causes issues

[Malix]

yes, x264 varies bitrate a bit, but if you set it to 55kbps, it does not, and I repeat, does not make it jump 1000 fold and back, some percentage maybe.
Colorspace does not have major difference to bitrate if you *specify it*, it just makes the videostream fit to whatever bitrate you just specified.
If you use CRF or QP -methods, then a variable bitrate, like you describe, is used.

x264 manual for bitrate: http://mewiki.project357.com/wiki/X264_Settings#Ratecontrol

bitrate

Default: Not Set

The second of three ratecontrol methods. Encode the video in target bitrate mode. Target bitrate mode means the final filesize is known, but the final quality is not. x264 will attempt to encode the video to target the given bitrate as the overall average. The parameter given is the bitrate in kilobits/sec. (8bits = 1byte and so on). Note that 1 kilobit is 1000, not 1024 bits.

to reiterate: you specify bitrate, it is used.

And yes, you can specify ridiculously high ratetolerance (default is 1%) http://mewiki.project357.com/wiki/X264_Settings#ratetol (don't really see the point to it though, as crf and qp exist).

so, even with ratetolerance of 100, your 55kbps video would at worst case scenario be 110kbps, wich would result in ~50MB for an hour worth of video.
Even if you didn't, according to math:

55kbps / 8 * 3600s ~= 25MB, lookitthat, 1000 fold error to the filesize you just said:

my 55kbit setting I use and I play say TF2, I can capture at around 22-24gigs a hour

So yes, you *ARE* actually using 55Mbps* (or 55000 kbps) bitrate, despite of what you claim.
edit: *atleast effectively you are, if you specified ratetolerance option as high as thousands of %

If you wish to convince me otherwise, disprove the math above, please. If I'm wrong, I wish to know of it & learn to better myself.

80kbit is more around 300-350kbit FRAPS/Lagloss for quality overall, but I don't know how to play it back at full speed as decompressing that high a bitrate into the pipe always causes issues

Probably player/decoding issue. VLC for instance can choke quite easily, but personally, zero issues with RGB lossless lagarith files (1080p, 30fps) playback or capture. Ut Video doesn't play in VLC, but has zero issues in WMP.

[ShamisOMally]

I'm just going on my experiences with the x264 codec I use, manually setting the bitrate and the different filesizes I get depending on video complexity