Video Recorder

What it says on the tin: a place to discuss proposed new features.
Post Reply
Novator
Gnoblar
Posts: 13
Joined: Mon Apr 11, 2005 6:39 pm

Video Recorder

Post by Novator »

It would be really neat if you could add a video recorder to Ogre

ps I know theres fraps, but it would be good if it was built in ;)
User avatar
pjcast
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 2543
Joined: Fri Oct 24, 2003 2:53 am
Location: San Diego, Ca
x 2
Contact:

Post by pjcast »

I don't expect a video recorder will ever be part of Ogre core... Though, a lib or plugin could be written that could do what you are asking.

Easiest way though, take a screenshot every frame of video you want, and combine it later into a video composition (which is best anyway, because realtime encoding while running your app will kill fps completely).
Have a question about Input? Video? WGE? Come on over... http://www.wreckedgames.com/forum/
User avatar
alphageek
Gnome
Posts: 365
Joined: Mon Jan 03, 2005 11:56 am

Post by alphageek »

Also keep in mind that if you have your own render loop, you can run Ogre in non-realtime at whatever FPS you wish. This is the approach I would take to generate the sequential images pjcast mentions.

For example, my top-level render loop does something like this every frame:

Code: Select all

		// modified from Ogre forums, post by nfz: http://www.ogre3d.org/phpBB2/viewtopic.php?t=6552&highlight=custom+render+loop
        FrameEvent frameEvent;

		if(Scheduler::getSingleton().isPaused())
		{
			frameEvent.timeSinceLastEvent = frameEvent.timeSinceLastFrame = 0.0f;
		}
		else
		{
			frameEvent.timeSinceLastEvent = frameEvent.timeSinceLastFrame = sinceLastS;
		}

        // notify frame listeners that a frame is starting
        _stop = !_ogreRoot->_fireFrameStarted(frameEvent);

        _ogreRoot->_updateAllRenderTargets();

        // notify frame listeners that the frame has ended
        _stop = _stop || !_ogreRoot->_fireFrameEnded(frameEvent);

I can easily manipulate the FPS Ogre thinks it's running at by changing the sinceLastS parameter. (This is important for per-time stuff like particle systems etc.).

Caveat: I haven't tested this for anything other than full speed (normal) and paused, but the technique should work.
Axiomatic: action-packed space shooter
TaskScheduler 0.3
User avatar
bugshake
Greenskin
Posts: 111
Joined: Sat Feb 26, 2005 1:12 pm
Location: Amsterdam
Contact:

Post by bugshake »

Also keep in mind that if you have your own render loop, you can run Ogre in non-realtime at whatever FPS you wish. This is the approach I would take to generate the sequential images pjcast mentions.
I implemented this once for a demo (which didn't use Ogre though). You have to make sure every time-dependent thing in your framelistener uses evt.timeSinceLastFrame. You can test this by comparing for example 1600x1200/4xAA in debug mode with 800x600 in release mode.

By the way, the results I got was gigabytes of screens, which no video-editing program I had access to could handle. Also, because of the smooth nature of computer-generated graphics, all compression algorithmes I tested failed miserably, for example a bird flying through a perfectly flat colored blue sky would show a trail for several seconds and fogged content would look terribly blocky and blurry.
User avatar
Kentamanos
Minaton
Posts: 980
Joined: Sat Aug 07, 2004 12:08 am
Location: Dallas, TX

Post by Kentamanos »

If you used a codec made for "real life" video, you'll definitely see artifacts. They basically use lossy compression techniques similar to the artifacts one might see in a JPEG file.

I'm not sure what codecs are good for rendered sources, but it seems like a lot of commercial games use Blink to do their in-game movies which are rendered (non-realtime, but still rendered).

I haven't looked at codecs for a long time, but I remember back then Intel's Indeo codec was good for animated material, and therefore might be OK for rendered stuff.
User avatar
bugshake
Greenskin
Posts: 111
Joined: Sat Feb 26, 2005 1:12 pm
Location: Amsterdam
Contact:

Post by bugshake »

Yes indeo did produce a lot better results then for example divx, however, it changes gradients to very low-resolution blocks (as in 32x32 pixels) and the compression ratio isn't very high. It produces the same artifacs in a clear sky until the next keyframe (every 15 frames for example).

I have never tried Bink, though judging by commercial games it eats a lot of CPU time, but then again it might seem that way because they're preparing other stuff in the background.
Mecha
Gnoblar
Posts: 9
Joined: Sun Feb 22, 2004 10:20 pm
Location: Greater Pacific Northwest
Contact:

Post by Mecha »

bugshake wrote:By the way, the results I got was gigabytes of screens, which no video-editing program I had access to could handle.
You would probably want to keep in mind your final output target--capturing at 1600x1200 isn't going to help much if you are going to output to NTSC(unless you want to enhance the FSAA effect by downscaling to 640x480). Converting your frames into a good working codec like DV or HuffYUV will also help in final editing. And, in the end, there's a reason video workstations are 90% disk and I/O bound..
bugshake wrote:Also, because of the smooth nature of computer-generated graphics, all compression algorithmes I tested failed miserably, for example a bird flying through a perfectly flat colored blue sky would show a trail for several seconds and fogged content would look terribly blocky and blurry.
That almost sounds like a problem in the encoder you were using--a good two-pass encoder at a decent bitrate(especially for Xvid) shouldn't have that much problem with it. What were the tools you were using to encode this video? Have you checked out the Doom9 guides?
User avatar
IoN_PuLse
Goblin
Posts: 220
Joined: Mon May 31, 2004 5:54 am
Location: Canada
Contact:

Post by IoN_PuLse »

Yes I can attest to using a 2-pass solution with xvid yielding excellent results :)
Post Reply