General > Off Topic

Codecs to use with DxTory

(1/10) > >>

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

+ 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
+ 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 (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?

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

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

MasterNobodies x264 codec (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

+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


--- Quote from: ShamisOMally on May 22, 2013, 06:11:31 pm ---LAME ACM 3.99.5
+Lossless audio capture at 192kbit

--- End quote ---

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.


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?

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.


[0] Message Index

[#] Next page

Go to full version