liteCam Game: 100 FPS Game Capture

liteCam Game: 100 FPS Game Capture

This compared to Fraps?
Simple question. I cant get Fraps because you can only buy it through paypal. So this seems like a much more convenient option for me.
< >
Показані коментарі 115 із 20
Made video here, left is litecam game (which is very similar to this steam version) with their Rsupport Mpeg 4 codec set to max bitrate 12000, right is Fraps

http://www.youtube.com/watch?v=kQL-Bii_S-s

Keep in mind though that they said they are rolling out a new codec in a few days which will improve performance. It is compatible with other codecs as well but I have not tested yet how it performs on them.
Автор останньої редакції: Sicris; 9 берез. 2014 о 14:59
i already have the fraps pro version. bought it like 5 years ago. i'm looking for something that records at a set resolution, as fraps doesn't do that. it'll record at your current screen resolution or half of that value. i'd like to record at 1080p, and i play at 2560x1600. any suggestions?
Made a new comparison video. This one is after 3/11/14 update.

http://steamcommunity.com/sharedfiles/filedetails/?id=237783142
Автор останньої редакції: Sicris; 12 берез. 2014 о 22:00
its all good. software capture as far as im concerned is garbage. im going with hardware capture.
Am still curious how the the RSupport codec compares with fraps quality-wise. They look almost identical to the eye so it makes it impossible to distinguish visually which one is more lossy than the other.

I'd assume RSupport since it has less bitrate to work with but at the same time I don't know if it's because it uses more effective techniques than FPS1 that it doesn't need that much. So am at a loss.
Автор останньої редакції: Sicris; 12 берез. 2014 о 22:15
I'd say the new codec from Litecam has a bit better quality than Fraps, but before it came out I used ffdshow (Uncompressed) with LiteCam
The more heavily you compress real-time the worse your game framerate will be when recording. The less you compress real-time the better your game framerate will be when recording. Sure the file size is larger, but you can compress it afterward to not affect your game framerate while recording.

Using default settings/codecs on both, this is how I see Fraps and Litecam. Fraps faster with less real-time compression, Litecam has smaller files with more real-time compression. I suppose you could use a different codec with Litecam to alter this.
Цитата допису 3DMightyMouse:
The more heavily you compress real-time the worse your game framerate will be when recording. The less you compress real-time the better your game framerate will be when recording. Sure the file size is larger, but you can compress it afterward to not affect your game framerate while recording.

Using default settings/codecs on both, this is how I see Fraps and Litecam. Fraps faster with less real-time compression, Litecam has smaller files with more real-time compression. I suppose you could use a different codec with Litecam to alter this.

The default setting for litecam's RSupport codec looks horrible. I tested it prior, the quality was inferior to fraps (lot of articating). The lower the setting the worse the quality becomes, set it to something lower than 6000 and it becomes more apparent. It only looks almost identical to fraps if I set the bitrate to 12000. Considering what I told you in the other thread about youtube and their horrible bitrate matching practices, I want it to be as close to lossless as possible.

My computer is a bit old but it's not exactly ancient either. It's first gen i7 and an HD 5850 and the games are running off an SSD. It should be more than suitable for recording a game running at 1280x960 (bullet hell or not) and a fighting game running at 720p, even dealing with real time compression.

However, even if you set the RSupport codec to something as low as 2000 (which I don't recommend because it looks horrible) and do as little processing as possible it still has the FPS issue. There is no slider option in the codec to change the compression rate or leave the files uncompressed so it takes up less cycles which is a bit of a problem. However with the release of the new MJPEG codec that might not be much of an issue anymore though I have yet to test it. Most people recording games have plenty of hard drive space but CPU cycles are a finite resource. However I'm not sure if it really is a codec problem because I've read on the forums that other people have the same problem as well when using different codecs so make of that what you will.

Those two "tests" that I did were stress tests. I put the first game at settings that I knew would give recording software problems normally. All recording software whether it is litecam, or fraps, or action, or bandicam or playclaw hate recording bullet hell games running at 60FPS (30 FPS it gives little to no problems but 60 always results in dropped frames for a computer with my specs), even worse is when the resolution is running at 1280x960. I made it like that on purpose to see which software can handle that kind of stress better, although that test was made with the outdated litecam game trial on their website so it's not relavent anymore.

The fighting game is a bit different, that one was made after the litecam patch. Ran that one 720p at 60 FPS but it's nowhere near as stressful as a bullet hell so there should be no reason it shouldn't perform well. I could have ran the game at 30 FPS and both videos would be smooth but that defeats the purpose of a stress test and it wouldn't be representative of a real world scenerio in which most people run it at 60 FPS while recording. I'll say this, they did definatly improve the program like they said they would, but there are still issues that need resolving. Both games were synced up and running off a separate SSD so loading times was not the issue. It may look like a small issue because it's lagging by only a few frames, but keep in mind that if it was running at 1080p or if the game was more graphic intensive it would be a much wider gap in dropped frames.
Автор останньої редакції: Sicris; 15 берез. 2014 о 1:56
Forgot to add that I can't find any information about the RSupport Mpeg 4 codec either on google or litecam's website or even the RSupport website. What bitrate do I have to set it to to look exactly like Fraps for a fair comparison (assuming it can get it exactly to the same quality as Fraps), what color space it uses , what is it's resolution limit. It's compression ratio. Nothing! I can't find any information on this codec which is ironic because they advertise their RSCC codec with so many data graphs and tables, but that codec is useless for recording games.
Автор останньої редакції: Sicris; 15 берез. 2014 о 2:28
While testing the new Rsupport MJPEG codec out, I just found out when playing it back in VLC that it's Planar 4:2:0 YUV full scale, same as Fraps. So yea this is definitely a marked improvement quality-wise over the RSupport MPEG 4 one that is not full scale YUV 4:2:0.

I gotta test this codec out soon now that I know this. The problem now is choosing what game to test.
Автор останньої редакції: Sicris; 15 берез. 2014 о 2:32
Bullet hell games can understandably can be rough for a compresser, probably 50% of the screen pixels change each frame. However, with FPS games that have continuous motion roughly 90% of the screen pixels change each frame (10% for the fixed status bar.) So I believe FPS games stress the compresser the most.

Many modern 3D games with high scene complexity in constant motion are already taxing the CPU quite a bit, with very little left over for compressing real-time. Older 3D games with lower scene complexity probably don't tax the cpu much to achieve high fps.

Anyone ever try profiling these programs to know for sure how much CPU the game uses and how much the compressor uses?
Автор останньої редакції: Hyper Sonic; 16 берез. 2014 о 13:28
Цитата допису 3DMightyMouse:
Bullet hell games can understandably can be rough for a compresser, probably 50% of the screen pixels change each frame. However, with FPS games that have continuous motion roughly 90% of the screen pixels change each frame (10% for the fixed status bar.) So I believe FPS games stress the compresser the most.


The reason I use Bullet Hell games (or fighting games, or even racing games) for a comparison is because those games are usually the ones that have a replay feature, so you are getting the same exact video each and every time to test multiple codecs across. So it's much easier and much more consistant to tell which recording software / codec performs better by syncing the videos and finding out if there are any dropped frames or slowdowns, even if it's a fraction of a second long.

That and that added bonus that even if there was a studdering issue caused by the GPU or a driver and not the software recording program, the fact that the replay function makes all the videos identical means that it should theoredically show up on all the tests, meaning much more accurate results.



Edit: However you can also use benchmark tests that come with games like shogun 2, arkham city, resident evil 5, etc, to get identical videos as well probably. The only issue is that those benchmark tests tend to be short so while finding if frames were dropped or studdering occured is still possible, you won't be able to tell how severe of an issue it really is in a short video.
Автор останньої редакції: Sicris; 16 берез. 2014 о 17:22
Well the GPU is involved in screen pixel generation, but compressing (taking what you have on the screen and describing it onto a file) I don't think uses the GPU at all, but don't quote me on that!

I've ran Quake 1 though 3 at 1920x1080 windowed with the resource monitor on the bottom 120 pixels (1920x1200 screen) and discovered that these games never take more than 15% of the CPU when locked at 60fps. BTW my computer was built in 2010 so it would be even less with 2014 computers. I was thinking that these games would make a good test of the compressor as the compresser would have 85% of the CPU to use without interfering with the game's framerate. Also none of them took up more than 0.2 gigbbytes of RAM, plenty leftoever for the compresser. I know Quake1&2 have replays, probably Quake3 as well.

Quake3 used less CPU cycles than Quake2 I believe due SSE support in Quake3. Quake1 used the most as it lacks the OpenGL hardware transform accel of Q2/Q3, and lacks the SSE support that Quake3 has.

I wonder if there's a performance monitor app that lists what % of the GPU each app is using.
Цитата допису 3DMightyMouse:
Well the GPU is involved in screen pixel generation, but compressing (taking what you have on the screen and describing it onto a file) I don't think uses the GPU at all, but don't quote me on that!

Varies per program, Fraps I know is dependant on the CPU while something like nVidia's shadowplay is GPU dependant for recordings.

liteCam though is CPU dependant.
Автор останньої редакції: Sicris; 16 берез. 2014 о 23:20
I've been doing a bit of testing, and I've found that with Fraps the main bottleneck is file writing. CPU and RAM aren't used much. You should really have a dedicated de-fragged drive with lots of space for recording videos especially if you're not using a solid state drive as the delays caused by the head moving simply destroys smooth framerate. At least this is the case for 1920x1080 @60fps recording.

Moreover if the game itself uses the hard drive regularly as well such as flying over terrain on World of Warcraft and Google Earth then you should really have 3 drives: 1 for the app, 1 for the recorder, and 1 for the operating system. However, a fast solid state drive with 1 gigabyte/sec transfer rate you might be able to get away with only one as solid state drives don't have head delays as it has no moving parts.

Also I don't think there's much lossless compression that can be done for constant motion through a 3D textured world.
< >
Показані коментарі 115 із 20
На сторінку: 1530 50

Опубліковано: 9 берез. 2014 о 13:36
Дописів: 20