Video Editor Friendly?

Tried to search for this but I didn't get any thread about if rFactor 2 replay format will be easier to work with on video editors instead of using Frapps or some other video convertor the file.

 

I'm sure you don't know what you are talking about.
Replay file has nothing to do with rendered video so it cannot be more or less friendly to video editors.
You just need to grab video or count on some internal renderer (like in rf1)

 

try this link

http://isiforums.net/f/showthread.php/1263-rFactor2-Replay-System?highlight=replay+fridge

says something about the editor has been removed.

 

So it simplify things.
I personally think that sim like rF2 shouldn't be '3in1' or 'wash&go' solutions. So I'm happy with ISI's decision.

 

Replay + Freecam + slow motion + Fraps = all you really need

Frame renderer is a great optional feature to have even if it does take a while the results are always flawless and you can apply copious amounts of anti-aliasing too.

So apart from higher fidelity replays for things like suspension movement (which is done, yay!)

I think a good usable freecam with FOV and DOF adjustment on-the-fly would be a improvement, integrated mouse smoothing and multiple playback speeds + rewind replays would be fantastic. Some of these things are already in rF1 btw, just needs a bit of polish/user friendliness.

 

They should just take a long hard look at iRacing's camera controls. They did a great job on that.

But I hope they leave the existing replay export feature in there. If I want to export a quick hotlap without any fancy stuff, I don't want to export in slowmo, then transcode it, then upload it. If you switch the codec rFactor uses to x264, you can practically export at 0.5x. Sure it doesn't look as good (no AA, ect) but at least it is fast and easy for simply trying to show a teammate a hotlap.

Here is an example. It isn't that bad looking and it is as easy as pressing one button and then uploading the results.

 

Theoretically you are right. In practice this 0.5x and worst quality (no AA) is pain in ass. And rF1 is very good example that such feature should not be bundled with a sim. Developing of such minor features (from simulation point of view) are often dropped by dev team. Good is if solution satisfy eny requirements from begining. But if not, or requirements going to be changed in time - customer end up with non fully functional solution.

I'm sure it is better to rely on some 3rd party soft like fraps, which is specialized in what is intended to do. Maybe in overall you will get result even faster

I remember some "great" ideas of new features of rF2. For example: "one-click video upload onto facebook". It is kinda similar.

 

Well that's to bad, I really would like to just open the replay file in my Pinnacle Studio and edit the replays into movies instead of cutting the video quality using a media capture software.

 

Well, that's the whole thing, isn't it? The replays are saved as data, not frames of video. The rF engine needs to (re)create the graphics from the data. It is essentially impossible, let alone impractical, to save video data of your replays from every single camera at the track (plus the 'on-board' cameras). Hence the replays being saved as data. I think that's what MaXyM was originally trying to say with his first post.

In any video game, no matter what, you WILL have to 'render' to a video format (i.e. .mov, .avi, etc.) from the game engine somehow. Asking to be able to use the replays directly in Pinnacle or any other video editing software is like asking the ability to edit a feature film given only the script as a MS Word document.

I also agree with ISI's decision to remove the editor from the Replay Fridge. All you really should need to do in-game is to export the video in some sort of easy way. What would be extra awesome is if they included 'passes' that can be pulled from the rendering engine (i.e. HDR instead of tonemapped, Z-buffer, etc.).

 

Ok.. I understand that now what you are saying but what was confusing to me was that file is under .VCR format and I have .VCR media format capabilities to read and convert another format like Mpeg2 on my Pinnacle. I figure it should have opened that file because I saw that it is in that format .

 

Remember that a file extension is only that. It doesn't actually mean it conforms to any particular file format specification, though obviously in many cases that is true and is what makes them useful. But in this case they could have called it .REP, or .RFR, or ... anything. So ignore the fact it has a 'known' extension - it's purely data for rFactor to recreate the events 'captured'.

On the down side this obviously means you need the engine to be able to actually pull video out of it, but the upside is you can move your camera anywhere in the game world and, to some extent, alter the speed of events as well.

This (as blakboks said) is basically what MaXyM was eluding to when he rather rudely said you didn't know what you were talking about.

 

I'm sorry if my sentence sounds rude. It wasn't my intention. It was just conclusion.

 

What would be really cool is if FRAPS could hold up the engine long enough to run the frame through some other codec like H.264. Then we would get the best of both. One pass encoding without having to do a second pass to trascode the massive FRAPS output. You would also have AA. This wouldn't let you do free cam but for quick simple hotlap exports it would be nice. Oh, the other advantage is someone could have a very slow machine and still be able to export because FRAPS could hold the engine as long as it needs to process the current frame.

But this would never happen without some sort of cooperation between the FRAPS team and game devs. Sounds good in theory though. If rF2 drops the export feature, my YouTube account will not get as much activity because I don't have the time to mess around with FRAPS.

 

The one thing I hate about Fraps is the size of the files it records. Just today I made a 4 minute video from a rFactor replay, I had to chop it down extremely just to upload it to Youtube, It was 1.03GB for a 4 minute video with 100% quality. LOL Ridicules. I chopped it down to 100MB and use DivX format so it wouldn't look to screwed up.

 

Your computer already have to run the game plus record the video stream, if you want it to be real-time compressed, I fear some computer would not be powerful enough.
Mine wouldn't at least.

 

Doug, FRAPS records uncompressed video which indeed will be quite large. As Gimli said, recording (full HD even) and compressing at the same time is still out of reach for the current level of processing power.

 

That is why I said it would be cool if FRAPS could hold up (pause) the engine (rFactor) while it compressed the frame. If it worked this way, even a 10 year old computer could produce silky smooth, full res video.

 

Hmm... it would also be cool if FRAPS could frame server to another machine.

 

Game engine progress is based on system timers. Even if you stop the game process, then after resuming it will make up that lost time (within some limits usually),

Unless game is written in a way that it allows external control.
But even if - video frame is something you may capture as long as it's displayed, but sound is not.

So no matter how this may seem logical from user's point of view, it's a nightmare from software's point of view.

The only way to get a perfect capture is when such feature is built-in in the software. This way software could push physics forward by exactly 40ms, render exactly 40ms of audio, render one high-res frame (perhaps even supersampled) representing current state and output all that into 25 FPS video stream. This is the only way to get production-quality video.

Having such feature is a big plus for software, but makes it more difficult to operate cameras while recording. So it would probably need some scripting mechanism for cameras aswell.



So to sum it up a little - we have to accept that things are not perfect with FRAPS and other software because that's just the way it is and nothing can be done about it. With this kind of solutions you will always have nothing more nor less than a compromise.
Also - rFactor may run at 40-60 FPS while FRAPS records at 30 FPS which means you get a small jutter in frame timing (sometimes you get two frames in a row of what rFactor rendered, sometimes you can skip frame).
Expecting it to become better or having some new features to control the way things are recorded is unfortunately pointless, because these are unrealistic expectations. You cannot expect perfection from this kind of solutions.


Only built-in mechanisms can guarantee perfect frame timing and excessive quality at the cost of not running in realtime, which produces other implications.