pouët.net

okay. thanks. Ill get back to you if i dont get it to work.

(which is perhaps what he feared from the beginning)

are you fucking instane. this capture took 3 gigabytes!!????

I used HuffmanYUV or something

a 2 pass XVID?? what fucking compression is that?

...which is the reason you need to encode it to xvid or some other format afterwards. read the WHOLE post, please.

(you can also do a single-pass encode to xvid directly from kkapture, but the quality isn't even close to what you can get with two-pass for the same bitrate)

and i used .AVI (DirectShow, OpenDML). is that the right one?

RTFM or use teh power of google: http://doom9.free.fr/xvid-vdub.htm

the DirectShow avi writer is fine when it works (because it can produce single AVI files >2gb), but dshow is kinda unstable in kkapture (due to the way kkapture works, dshow doesn't have time to properly initialize before kkapturing starts). the vfw avi writer is less troublesome, but needs to split large videos into several avi files which you need to join later (also with virtualdub, usually).

i think it's good now. i got it down to 108 megabytes and it looks quite okay. even though its just a four minute demo. a movie in 2 hours take 650 megs i dont understand how they do it yet. anyways i dont bother make it any smaller today. ill take a break from this shit now. thanks for the help so far...

ruderudy: RTFM should be an enough rude(rudy) answer

ruderudy: movies are far easier to compress than demos. a big percentage of shots in movies is dialogue, with the actors talking in front of a mostly static background. in demos, most of the image changes every single frame. also, you'll usually capture demos in AT LEAST 30fps, whereas movies use 24fps; different frame rate doesn't make a big difference when you have small differences between frames (as in the already mentioned dialogue shots), but in demos with lots of movement, cuts and flashes it hurts compression significantly.

the different types of videos we made at breakpoint show the differences nicely. demos were encoded at 50fps (since we have pal source material), 4mbit/s. this is a lot, but coming from analog devices there's a significant noise level (still clearly visible in the videos); filtering that would help a lot, but also severely blur demos that use a noise layer to get a grainy "lo-fi" look (after encoding such a demo, the graininess is gone and all that's left is a splotchy mess). our presets were designed to work well even in a worst-case scenario, so while the 4mbit may be somewhat excessive for the source material we actually had, the results came out great (IMO). in any case, certain demos (prime example would be deities by mfx or track one by fairlight) still are completely blurry and with visible artifacts even with 3.2mbit at that resolution, and only start looking acceptable around 3.6mbit or so.

seminars had a 25fps/1.2mbit video stream, and yet they look virtually perfect, and would probably still do so at 700 or 800kbit (will toy around with that for next BP :). this is what matches the "dialogue" shots i talked about, which is what most video coding methods are optimized for.

the vista speech coding compo/opening ceremony is also 25fps/1.2mbit, lower lighting level (thus more noise), and hand camera (a lot more shaking), but still looks good because aside from the "global" motion due to camera-shaking, there's not too much happening between frames.

finally, the BASS concert is also 25fps/1.2mbit, yet lower lighting level (thus yet more noise) and also fog, light flashes and relatively high number of cuts. the quality is definitely not optimal here, with lots of artifacts in some places, but then again it's difficult material.

for reference, dvd/tv show material is usually 24/25fps and gets encoded with around 1mbit/s for video (mpeg4 ASP) or even as low as 500-600kbit/s at comparable with h.264 (which rocks, but takes a lot of cpu to decode).

all bitrates given are averages over the whole stream, btw; the whole point of twopass encoding is to spend more bits where it helps quality instead of wasting a few hundred kilobits/s on removing the last few pixel errors from nearly static screens.

yeh. i think i get your point :P

I have the problem that no matter what I set in the encoding configuration kkapture seems to use the default setting of that encoder. The moment I leave the encoder selection window the settings seem to be resetted. When I re-enter via "Pick..." the encoder configuration dialog shows the default settings again.

Has someone some infos about this?

lol, get a life

ryg: your directsound capture hangs when after using Lock with dwBytes=0 while it works when using ms's dsound api (i use that to save a few bytes).

Hi ryg. I wanted to make some additions to kkapture for myself. But I'm running into some problems here.
- Downloaded Detour Express 2.1 and compiled it. Added all the necessary paths to my Visual Studio 2005 Express. Compilation failed because some functions couldn't be found.
- Tried downloading Detour 1.5. Couldn't even compile it. Lots of errors probably because of the new compiler.
- The libs + include were there, so I tried changing paths to 1.5 and compiling kkapture. Same functions were missing: "DetourGenPushad", "DetourGenJmp", ...

Any hints?

The stuff I wanted to add was to be able to dra'n'drop an exe to kkapture and to make kkapture correctly close the avi-file when the application crashes or is forcefully terminated, which happens/I need to do with some demos...

...found the #define ;)

kkapture doesn't open the AVI file itself; it injects code into the application to do all the capturing. so if the demo crashes, the capturing code does too. there's no easy way to get around that.

You inject code that calls you function stub first, which in turn calls the real functions (dsound/opengl/whatever)...
Does kkapture.dll terminate when the application crashes? The process for the demo is created by kkapture.exe.
Would proper closing of avi files be possible if:
- The application closes its window?
- The application is idle for an amount of time (10-30 seconds or so)?

The problem I have with some demos is that the demo closes the window but doesn't exit properly. I you kill the process manually the avi file is broken...

Then don't kill the process, just use Ctrl-Break. kkapture catches that one and handles it properly (usually).

Worked with CTRL-BREAK. Thanks.
Didn't understand that the hook works from anywhere not just the application window, sorry.

Are you interested in people adding adding entries to the "working_demos.txt" file that are not already there?

this one worked:

WORKING: Unik - Pluxity (final) -> use fullscreen version and press CTRL-BREAK after the window has closed, because it is still running in the background then...

wow rarefluid, amazing! !! :)

http://www.pouet.net/prod.php?which=8354

I want to kkapture this demo but I get an error
any help how do to this?