Register
Events
Popular
More
Post #1
(Cross-posted from the Steam forums)
Obligatory screenshot:
What does it do?
SrcDemoČ lets you render smoother movies, faster.
Smoother, how?
By using frame blending. Frame-blending is not a new technique. It involves rendering a movie at a very high framerate, then blending those frames together into a lower framerate. This gives the final video a smoother feel.
However, these frame are quite large in file size, and if you want something very smooth, you would thus require a lot of disk space in order to store all those frames. This is where SrcDemoČ comes in.
Faster, how?
SrcDemoČ creates a virtual filesystem that sits within the game's directory. When the game tries to write image files to it, those images get caught before they get written to disk. Instead, they are kept in memory. After a sufficient amount of images has been caught, they are blended together, and one single frame is written to the disk, in another directory of your choice, in the image format of your choice.
This not only allows you to render movies a lot faster (since frames are not written to disk, and the disk is slow), but also smoother, because you can set the framerate as crazy-high as you want and the disk storage needed will not change!
Example movies:
* Example in Portal (Blendrate: 25; Shutter angle: 360 degrees)
* Example in TF2 (Blendrate: 75 for Scout and Medic segments, 45 for the rest; Shutter angle: 180 degrees)
* Example in Garry's Mod
* Example in Portal 2 (Blendrate: 9; Shutter angle: 360 degrees) (Ignore the screen playing the Animal King movie too quickly... Source Recorder bug which makes the playback of those movies ignore host_framerate)
* Without frame blending: Equivalent video in Portal 2 without frame blending
Disclaimer: Those were made with SrcDemo, not SrcDemoČ. However, both tools do exactly the same thing, only the latter does it much faster.
Installation:
Linux
There is a PKGBUILD available and an openSUSE build service entry. The openSUSE entry is unsupported as I am not the one taking care of it.
OS X
The OS X version only works on the command-line. It is downloadable here. It requires a working FUSE implementation (Fuse4x, OSXFUSE, or MacFUSE). To use, run the following command:
WindowsCode:/Applications/SrcDemoČ.app/Contents/MacOS/srcdemo2 --srcdemo-cmd
SrcDemoČ comes with an automated installer, but relies on two external components. Here is everything you need:
* A 32-bit Java runtime environment (even if you are on a 64-bit machine).
* The Dokan library (version 0.6). The library is only available as a 32-bit interface, hence the 32-bit Java runtime requirement. SrcDemoČ does work (and was developed on) 64-bit Windows, however.
* SrcDemoČ itself.
How to use:
* Download and install all of the above.
* Open SrcDemoČ.
* Select the folder in which you will tell the game to save frames. It must be empty. It is suggested to create a folder named "srcdemo" inside the game's folder, just for this purpose.
* Select the folder in which you want the final, .png frames to be saved. This can be anywhere on your computer, including other partitions, but must not be the same folder as the previous one.
* Select your recording parameters:
- Final videos FPS: The framerate of the video you want to create in the end. Hint: If you want to upload it to YouTube, leave this as 30 fps.
- Motion blur blend rate: The number of raw frames from the game that will be blended inside each final frame. This can be as high as you want, but going beyond 50 yields very little improvement.
- Simulated shutter angle: Simulates the rotary disc shutter of cameras. Usual cameras have a 180-degrees shutter, which means that the film is exposed during 50% of the total frame time, and missing 50% of the action. Hint: Recommended values are from 180 (for a cinematic feel) to 360 (for butter-smooth-ness to a point that may be considered too much by some people). This has no impact on performance.
- Effective recording FPS: This is not configurable; this is the framerate that you will have to tell the game to render at. It is the product of the final video framerate and the motion blur blend rate.
* Press "Activate" and wait a few seconds. This will create the virtual filesystem in the folder you have selected at the beginning.
* Open your game, run your graphics config, etc.
* Type host_framerate n, where n is the number given as "Effective recording FPS" by the application.
* Start the movie: startmovie srcdemo/someprefix_. Make sure that this will make the game output frames inside the folder you selected at the beginning, and don't forget to put a prefix, for your convenience.
* Start the demo file or whatever you want so that frames are produced: playdemo somefile.
* Grab popcorn.
* When it is done, end the movie: endmovie. If you don't do this, the .wav file will be corrupt.
* You should now have all the final frames (as .png files) in the folder you selected in the second step, as well as the .wav file.
Open-source
SrcDemoČ is fully open-source and distributed under the 2-Clause BSD License. The source code is available on Google Code.
Credits
* Mythee, for the icon/logo artwork
I would love to see videos you can create with this tool! It would also be nice to tag videos you upload on YouTube with the tag "srcdemo2". Thanks!
-
-
Woah. Nice work.
-
This is sure going to be useful, it saves me from doing frame blending manually, Thanks
-
Holy shit definitely using this
-
WindPower. I don't say this enough. I love you.
-
Wow, great job. Very useful
-
I've installed Dokan but it says Dokan is not installed. Do I need to restart the computer after installing Dokan before using this?
3000th post
-
Possibly... I didn't need to restart personally. Make sure you get version 0.6, the other versions will not work.
Thanks everyone else too~
-
May I ask what you use to compile the frames and sounds?
Edited:
And then save it as, for maximum quality?
-
For the sample videos above, I used Chris' max quality config merged with my own Portal wiki walkthrough config. I then put back together the frames with Vegas 9, and exported with the x264 encoder in lossless mode (make sure you check "Zero latency", or else crap will happen), and 48 kHz PCM audio.
There is a bug in Source Recorder that causes the .wav file produced when rendering at high framerates to be severely out of sync with the video. This is not SrcDemo's fault, but you can work around it by re-rendering your demo at a more reasonable framerate (40~60) and using the .wav file from there with the frames from SrcDemo.
Also, someone on the steam forums created a sample video on Counter-Strike: Source.
-
Awesome tool, I'll be using as soon as I get some Source game video to render. Thanks.
-
Def going to be using this, great job WindPower!
-
Been waiting for something like this for L4D2.
Can't wait to try this.
-
Just tested it out, and I gotta say the difference is astounding. Only downside is that it takes a helluva lot longer to record, about 2-3x longer; but in the end it's worth it.
-
Thanks!
I do feel I need to clarify a point here though: The render will take a lot of time. It will be slow. However, it will be much faster than the time it would take to render the same demo (with the same level of smoothness) without this tool, because not all the frames are written to disk; hence the word "faster" up there in the title. Obviously, compared to a regular, non-smooth render, this will be slower.
-
I am getting Dokan is not installed even tho it is. I'm on Windows 7 64bit and yes i have java 32bit
-
I LOVE YOU.
HAVE MY BABIES
-
Did you reboot?
Edited:
Thank you kind sir :3 I gladly accept your offer.
-
Alright, so I played with it for a little while, and here are two things I noticed:
• I think the tool doesn't like capturing frames from the same directory twice. It just won't detect the TGAs being recorded there again (yet the folder was empty and no problems were reported)
• You can't "de-activate" to go select another directory without restarting. Is this by design?
-
1. Make sure you don't have two instances running at the same time (and check the process list); make sure there's no two instances trying to have the same folder mounted! Additionally, the "Activate" and "Exit" buttons take a few seconds to do their job, so make sure you're not too quick to start recording or to remount. You can check in Explorer if the folder is mounted properly by looking at the size column (it should say something impossibly huge), or the icon of the folder on certain versions of Windows 7. You can also just try saving a text file in it with Notepad and check if it gets written to the other folder.
Also quite importantly, don't use the same prefix for image files in the same run (i.e don't do startmovie srcdemo/something_ and then startmovie srcdemo/something_ again). It might work, but it'll probably get confused.
However, you should be able to do multiple renders without restarting, if you give them different prefixes. You should even be able to do parallel renders, if you somehow have two Source engine games running at the same time. I don't recommend that though...
2. I wanted the "Exit" button to actually be a "Deactivate" button, I really did, and at the last moment when I actually implemented it, I saw the following message:
"This version of the Dokan library can only mount directories once."
Which means that the while it is possible to unmount something, it is not possible to re-mount anything later, which would make it silly to have a "Deactivate" button if it forced you to restart right after. So to be able to re-mount something, the whole program has to be restarted. It's sad, but that's how it is :( It pisses me off too. Sorry...
Thanks for all the feedback everyone. I am currently working on adding a "debug mode" so that I can get a better idea of what is going wrong in certain cases.
-
yes i did i even tried to reinstall still no luck
-
I'm thinking you could probably make the program write a batch file so it relaunches itself in a matter of seconds :p
The only other thing this would possibly need is motion estimation methods to smooth out the blur even more, but yeah
-
I honestly think frame blending is terrible. It just blurs everything up.
-
frame blending is the best method for motion blur, what
it only "blurs everything up" (no it doesn't) when you set the framerate too high and render out to a really low FPS video
and will this program actually work with L4D and L4D2 seeing how host_framerate is locked/missing?
-
Left 4 Dead will not work with Source Recorder, as you stated; In l4d1 there is no Host_framerate command and in l4d2 the command IS existent, but the client recording system will not properly display zombie positions in anything higher than 240 FPS.(they jump around)
Obligatory content.
-
Indeed, it probably won't work with Left 4 Dead / Left 4 Dead 2. It'll work if they fix it...
Anyway, I released a new build today. You can download it from http://code.google.com/p/srcdemo2/downloads/list as usual.
Changes include:
- A "Deactivate" button which will restart the application (Thanks Max of S2D)
- A new debug mode (ory25: This will not fix your problem, but at least it'll provide more info, so please try it out)
- Tighter thread synchronization around byte buffers when saving images (this will make things slightly slower but more stable)
- A bounded PNG saving queue which should fix memory/CPU issues when rendering with low blending rates
- Changed default blend rate from 25 to 32 to match SFM
- Will attempt to detect if something is already mounted in the mountpoint, and if there is, will attempt to unmount before mounting itself (might fix Max of S2D's issues, not sure)
- Increased max output framerate to 600 and max blendrate to 1000, for the really, really, really crazy out there
- Proper singular/plural forms on numerical text fields
Uninstalling the old version before installing is recommended, because the startup menu has changed from "SrcDemo2" to "SrcDemoČ", so if you don't uninstall the previous version, you'll have two startup menu entries. Sorry about that; hopefully this won't be necessary in the future.
Known bugs:
- Can cause a BSOD if you specify a path with NTFS symlinks in it as mountpoint (will be fixed soon hopefully)
Upcoming features:
- Audio only mode where all frames will simply be ignored; useful when you want to re-render the demo but only want the audio, as it will be much faster if all frames are completely dropped
- Video only mode; this is useful when you render with high blendrates and know that Source Recorder is going to produce an out-of-sync .wav file; might as well ignore that .wav file right from the start to save the significant audio disk I/O
This, however, will not be implemented. There already is software to do this, if you really want to, but:
- It is very, very slow
- Compared to simply increasing the blendrate, the result is of poorer quality and takes much, much longer
- It would probably take so much time on slow computers that Source Recorder may give up (if it can't finish saving a .tga after a certain timeout, it will cancel the render)
- To be realistically fast enough, it would need to be computed on the graphics card, which is already quite busy rendering the frames of the game
tl;dr: Increasing the blendrate will provide better results, and will provide them faster; motion estimation is best left to postprocessing. Thanks for the suggestion anyway, I appreciate that.
-
They wont fix it because its not a problem for them, its just the way Source is optimized in L4D to handle the amount of zombies and their display.
Tl;Td - Its not going to be fixed because its designed that way.
-
Amazing need to test this out.
-
Idea for another feature, too, which could possibly be interesting: something which displays how many TGAs are getting processed per second. Kind of like a framerate counter.
Could even be useful in certain cases, like knowing which quality/speed ratio to take.
Also, I made a 2 minute test video! :D
-
I made another one with a blend rate of 64. Don't bother with that much since 32 is fine
Odd glitch about half way through. I should also change the firing sound as well
-
Thanks, I'll make sure to implement that~
Much thanks for the video, too. I already saw it because I am subscribed to you, but it has given SrcDemo some welcome additional exposure, for which I am very thankful.
That looks sweet. Not sure why the viewmodel froze midway through indeed, but as you can guess that's a problem on the game side.
-
It often happens for me when I'm using a high number with host_Framerate and startmovie after I activate certain triggers
-
yeah, in my experience, setting host_framerate around 400 or 500 and more results in pretty bad glitches
-
Could someone please write a good tutorial to converting to uncompressed avi? Currently when I try ot do this with tga's and wav's in virtual dub, it makes the frames black and white and rearanges part of the frame. Or it is very framey when playing and lags adobe premier and quicktime and windows media center. But when i convert it to xvid h264, the video turns out fine. I want this best quality for my videos, so I think I should be using uncompressed footage.
-
If you're uploading to YouTube just use the 264, YouTube will convert it anyway.
-
When editing the footage, a common myth says to edit uncompressed footage then export it into mp4. When I turn the tga wav into an mp4, its compressed before I edit it in adobe premier.
-
A general rule of video editing is to never use lossy format until the final render. That way, there is no useless loss of quality. That is why SrcDemo saves frames in .png format.
The reason your video is "laggy" (choppy) in your video editor is because all those lossless frames are very large and very numerous, but you requested the video to be played in real time (as fast as it should play normally); as a result, your computer cannot keep up. The disk is too slow to serve those images faster than the video has to be played, hence the choppiness.
However, when you render your video, your computer is not constrained by time, so there is no loss there. That is why the final video is good.
Most video editors have a pre-rendering/render-to-memory feature which lets you select a portion of the video and render that part, saving the frames in RAM. Once that is done, that section of the video will be very fast to read, so you can play that part in real time. This is useful when you want to do things like synchronizing the video and the audio track. I don't know how you do it in Adobe Premiere, but in Vegas, it's "Shift+B" (quite an awkward shortcut) after having selected a part of the video.
-
Beautiful. How did you go about the fluid weapon movement?
-
Use UT Video to have a lossless AVI that isn't as big. It's an excellent way to save space :D
http://umezawa.dyndns.info/archive/utvideo/
-
What is this wizardry and why have I only heard of it now?
x 57
x 28
x 2
x 1
x 1
x 1
x 1
x 1
Informative x 1
Funny x 1
Disagree x 5
x 1
