ExKode Forum

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

Lagarith http://lags.leetcode.net/codec.html (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 (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/ (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!

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

Quote from: ShamisOMally on May 22, 2013, 06:11:31 PM
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.

*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?

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.

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

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:
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. :)

Quote from: ShamisOMally on May 23, 2013, 08:05:44 PM
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.

Quote from: SirCrest on May 27, 2013, 10:09:20 AM

Quote from: ShamisOMally on May 23, 2013, 08:05:44 PM
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

Quote from: ShamisOMally on May 27, 2013, 08:46:09 PM
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 (https://en.wikipedia.org/wiki/Metric_prefix))

Quote from: Malix on May 27, 2013, 09:00:58 PM

Quote from: ShamisOMally on May 27, 2013, 08:46:09 PM
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 (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

Quote from: ShamisOMally on May 27, 2013, 10:50:33 PM
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:

Quote from: ShamisOMally on May 22, 2013, 06:11:31 PM
-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.

Quote from: Malix on May 27, 2013, 11:18:44 PM
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

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 (http://mewiki.project357.com/wiki/X264_Settings#Ratecontrol)

Quotebitrate

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 (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:

Quote from: ShamisOMally on May 28, 2013, 12:10:09 AM
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.

Quote from: ShamisOMally on May 28, 2013, 12:10:09 AM
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.

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

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

I stopped reading here. I have to comment first that before I read further.

wtf are you telling?

Lossless is LOSSLESS.

If you record in RGB even colorspace is lossless recorded. Otherwise it would be not a lossless codec.

The lossless codecs use lossless compression. simple as that. They are NOT lossy.

if you want a lossless encode by x264.

constant quantizer @ factor 0. this activates x264's lossless mode. Bitrate fixed encode is never lossless. bitrate mode uses b-frames and other lossy compression techniques. This is NOT lossless. It begins already with b-frames and p-frames which are NOT lossless. And you HAVE these. Also with insane bitrates. God damn it. Learn more about encoding before you tell so much bullshit here...

Quote+ Has lossless & lossy options

Where ut video has lossy options? There is only compression ratio, thread amount and colorspace. Where you see a lossy mode?

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


+Lossless audio capture at 192kbit

Made my day  ::) ;D ;D ;D

MP3 and lossless. wow.. only wow... cant even believe that you wrote that. insane ..

Quote-only captures in Stereo

you dont need more. stereo is optimal for our purpose..

Quote from: De-M-oN on May 30, 2013, 07:19:40 AM

Quote+ Has lossless & lossy options

Where ut video has lossy options? There is only compression ratio, thread amount and colorspace. Where you see a lossy mode?

For some reason I've always thought that YUV422 in Ut Video Codec is lossy as http://umezawa.dyndns.info/archive/utvideo/utvideo-12.2.1-readme.en.html#fourcc (http://umezawa.dyndns.info/archive/utvideo/utvideo-12.2.1-readme.en.html#fourcc) says that all but YUV422/420/ have a bit lower range than RGB/RGBA... but yea, you're probably right that it isn't "lossy" per se, just the colorspace conversion is. Fixing my post.

I'm out

I should have known better to get into a discussion over codecs, so much epeen and people jerking themselves off to "MAH CODEC IS BETTER, UR'S SUCKZ!1!" crap all these threads fall into

Seriously, get a life, I'm thoroughly turned off from discussing codecs ever again on this forum cause people start stating their opinions as facts like rere's "MY CODEC IS BEST!" crap this thread has turned into.

This thread was supposed to be "What codecs you like and why" and like I expected and pointed out a page ago, nobody can respect other people's opinions and start bashing everything.

Go have fun with your codecs, I'll be using mine.

Learn to distinguish facts vs opinions.

lossy codecs are by nature lossy and shouldnt be used for capturing. Lossy compression uses more cpu power and you can only use vfw codecs for capturing. but good codecs like h.264 need a more advanced container than avi. Further thing: due to the nature that lossy compression takes way more cpu power than lossless compression you need to use fast settings.
re-encoding after your capturing your lossy material again lossy is quality-wise suboptimal.
That has nothing to do with a fucking opinion. This is an objective fact.

Why so much people arent able to distinguish facts vs opinions?

But the best thing you brought up was your statement that lossless codecs arent lossless. And that it wouldnt be possible to capture without any loss videodata.

Seriously you cant mean that serious??

And you compare by bitrate with lossless video, where bitrate is irrelevant. If a lossless codec reaches low bitrate, it makes it a good one. Because it could compress very well without doing a lossy compression.

Wow... This thread derailed. lol...


Anyways, I want to give the UT Codec a try (been using Lagarith), but when I installed it I actually got 6 codecs added to my list. Any recommendation on which one would be best for recording Youtube videos with minimal impact on framerates and HDD space? :P

420, bt601

at setting choose dividor 2.

Quote from: De-M-oN on June 19, 2013, 09:21:29 AM
420, bt601

at setting choose dividor 2.

any particular reason not to use bt.709?

I think you can use it as well.

The previous versions used bt601 though.

afaik bt.709 has a bit better colors, and in some cases it looks a bit better than bt.601, atleast in virtualdub's RGB-cube it looked like it had less severe color banding. But dunno, the difference is quite small & could have been just a testcase where bt.709 seemed to perform better.

Will it ever be possible to use the x64 versions of the ut video codec with dxtory?
and it seems like the 13.X version added some new codecs(?). I used YUV422 so far since i got some performance issues from time to time when i used the RGB or YUV420 codec (writespeed of harddisk is ~110MB/s ||| processor: i7 930 @ 2.8 GHz ||| 12 GB DDR3 RAM ||| GTX660TI graphiccard).
i use this codec only for "modern" pc games (like Borderlands2) and i'm recording in 1920x1080 @ 30 FPS with PCM audio 48khz stereo for ingamesound and 48khz mono for my voice (using a rode podcaster usb mic).

Should i switch to one of the newer codecs of version 13.X (i'm currently using a 12.X version)?

For SNES/Retro games i'm using the lagarith codec as well. however i had a lot of performance issues with the lagarith codec as well, that's why i'm using the ut video codec for "modern" games. for me it works better than other codecs.

I'm also having a bug the original dxtory codec. whenever i open dxtory encoded file with my media player classis my explorer.exe gets stucked and when i restart the explorer.exe process i cannot delete the dxtory video files. i can only delete one video file at a time when i restart my computer. after that i have to restart again to delete the next video file.
that was the main reason why i was searching for new codecs :)
anyone else got a similar problem with the dxtory codec?

QuoteShould i switch to one of the newer codecs of version 13.X (i'm currently using a 12.X version)?

you definitely should. There is finally that slowness bug of the 420 fixed ..

I've just registered only to say you people are unbelievable and to thank to ShamisOMally for his suggestion, thank you.

Quote from: D-O-M on September 27, 2013, 06:51:43 AM
I've just registered only to say you people are unbelievable and to thank to ShamisOMally for his suggestion, thank you.

Oh you're welcome, I'm glad I could help in some way

I just got done running a brief test with  x264vfw  and was actually pretty surprised..   I'm hoping to tweak it a little to retain as much detail as possible, and/or boost compression without  hurting the ability to record @ 30fps realtime.

But for what I got,  a 4.57GB (2.0 PCM-16bit) file for 35 minutes (give or take a few seconds) of play time,  I was quite impressed..    It sure beats  trying to tweak the game options or lowering resolution, spanning disks etc (and having to wait for those files to assemble) all just to maintain recording speed.

I was Googling "Best Video Codec for Dxtory" when I found this thread.

Shamus has no idea how things work. 2nd, I saw after registering that someone said that THEY registered to thank Shamus? That HAS to be Shamus talking, because although his codec is fine, it's not a better option than a lossless codec.

He sounds like a paranoid schizo with the whole pissing contest thing. No one in the thread at ANY point said that ANY codecs were bad, or in any way not OK. No pissing contest, just literally a simple schooling on the difference between lossless, and lossy, and mbits, and kbits.

I truly believe this entire thread could be one person arguing with himself with how weird I feel reading these posts.

Thank you Malix, and Sircrest.

@SidedTech

A) I am schizophrenic, thanks for asking

B) Just because you don't like the codec, yet two other people did, you start with the "Its the same person!" bullcrap? Are you ten-twelve years old?

C) Why would I wait over a MONTH AND HALF LATER to respond back to "Myself" if D-O-M was indeed me? Is Zach also me? It took him two weeks later to make that post

My only conclusion is you're a fricken dick, you need to grow up.

Anyways, BBIAB after texting Masternobodies new AMD VCE x264 codec, which offloads entirely to AMD's GPU, so no CPU encoding

*EDIT2* Review of AMD GPU hardware h264 encoding here, along with settings I found most useful http://forum.exkode.com/index.php?topic=675.0

Thanks for all the info Shamis!

The LameMP3 codec is awesome! it saves a lot of space and its quality is really good.
About the video one, I always use the lagarith. Zero problems and good stability

Regards,
John

why recording audio lossy then?..

PCM 44100hz, 16bit uses not that much either, there is the video the main factor of filesize.

MP3 uses much more cpu due to the compression.
There are also better audio codecs than mp3, like vorbis, nero aac etc.
If you recompress later your video - you do a 2nd lossy encode of your audio - bad for your audio..

*redacted

why you post that twice?

http://forum.exkode.com/index.php?topic=640.msg2432#msg2432

here my answer.

Is there any codec that strikes a balance between the high compression of x264vfw and less compressed codecs like Lagarith and Ut?  Lagarith doesn't perform well enough to record in 1080p30, Ut does but the file sizes aren't viable for me currently (just had a hard drive die on me and the drive I record to now really can't handle 2GB/min, I dare not even think of the lifespan), and x264 performs extremely well, has a great filesize, but as OP said, is basically unusable in Sony Vegas.  I can't even get files to open with Vegas without adding "--keyint 1" to the command line, and even then the preview playback makes them completely non-viable for editing.

Anyone have any other suggestions?

If you have NVidia card, the geforce experience's shadowplay captured files work pretty well in my sony movie studio 12. I know it's not a dxtory usable codec, but might still work as a temporary solution until you get a new harddrive.

Though, you'd need to think of some other way to record microphone if you want it on a separate track, which is a bit lame :/

edit:
did you try enabling the "fast decode" option in x264vfw?

MagicYUV compresses almost as good as lagarith, but while that being very fast.

http://magicyuv.com/index.php/about-magicyuv

QuotePerformance

MagicYUV was designed from the ground up to be as fast as possible. During the design of the codec, special choices were made, each of which result in big gains of speed, while minimally affecting compressed video size. These compromises usually meant a 1-3% drop in compression ratio, while giving a 50-100% speed improvement.

The codec is multi-threaded and fully supports multi-core CPUs with near-linear scaling. To further enhance performance all internal frame processing is SSE2 optimized.

And yes the codec is fast.

Use the settings of the image:
http://www.letsplayforum.de/index.php/Thread/138529-MagicYUV-Ein-neuer-Lossless-Codec/

...and why haven't I heard of this MagicYUV before. This thing is a beast. Thanks De-M-oN!

Quote from: Malix on December 08, 2014, 05:11:38 PM
edit:
did you try enabling the "fast decode" option in x264vfw?

Yes, I have that option enabled.

Also, I was hoping this MagicYUV would be a solution, but it's outputting at 200MB per five seconds, which would be totally non-viable even if I were fortunate enough to have a completely free hard drive to abuse with that much writing.

It is not recommended at all to already record lossy.

You do the 2nd lossy re-encode and youtube even the 3rd then. If you dont care about quality - go for it ;)
Otherwise you shouldnt record lossy already ..

A HDD with excellent writing speed costs only 45 €.
A HDD is not a SSD. You can write high amount of data. It wont directly die lol.

http://geizhals.de/seagate-barracuda-7200-14-1tb-st1000dm003-a686480.html

very good HDD. Writes 196 mbyte/s. There are also variants with bigger size, just take care that its the 7200.14.

I found Motion JPEG to be awsome on other software but they have created their own codec I believe.

For video editing it's actually great as each frame is new JPEG image and the CPU usage is very low! I think M-JPEG with Mantle will be a awesome recording method that will have no impact on game play on BF4 even at 1440p 135% resolution scale at 120hz on 290x crossfire set up, being able to record 60fps easily on DX11 basically 4K at 120hz (120fps recording would be magical) I couldn't achieve it on DX11 but I think Mantle could do it ;) The other software can record 120fps 4K but I think DX11 was the limiting factor or I only had a 4770k CPU.

The main problem is also the HDD. You look for good cpu, good gpu, but everytime people forget the HDD. Data isnt going via magic on the drive.

For what you need 4k 120fps to be honest? :S

DXtory needs a Motion JPEG codec it's really great on other software.

Hi I've been using magicYUV as recommended here and its great, but... can anyone recommend something to re-compress it with? 2 minutes of HD video is nearly 3GB which is fine but it's going to take forever to upload to YouTube... (yes I have a slow connection)

Can anyone recommend anything to re-compress? I'm not bothered about quality (its youtube afterall) but AviDemux doesn't recognise the codec (get a green screen/no playback) VirtualDub + XviD does recognise it but is there anything more modern? Something with an x264 encoder for instance?

thanks.

MeGUI :)

And thats the recommended way anyway: Recording lossless and then encode it on your own with x264 to get it uploadable.


Its not recommended to record already lossy and re-encode the lossy again. This would lessen the quality at youtube even more.

Hey guys!
Could you please recommend software for encoding videos recorded with MagicYUV codec?
As I understand Handbrake does not support MYUV :/

MeGUI.

Thanks De-M-oN! :)

Quote from: Malix on May 15, 2013, 02:23:28 AM
Let's make a tread of good codecs to use with DxTory, list their strenghts and weaknesses.

Lagarith http://lags.leetcode.net/codec.html (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 (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/ (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!

How do you set up MagicYuV for best performance and quality?