Quote:
Originally Posted by LigH
This is no satisfying amount of information. Never trust in a filename extension, there is always a chance that it has been renamed for the craziest reasons (e.g. people don't know how to assign a media player to an unassigned but correct extension so that it will start playing after a double-click in the Explorer).
To help us helping you, do an analysis of this source file using MediaInfo, and post the result in "Text" format in a CODE block (or in a pastebin service).
If you are sure that it is an AVI because you made it, you may also know which codec was used; 115 GB is really huge, so it possibly contains completely uncompressed video. It would be a pity to have uncompressed RGB video saved, what a waste of space, and furthermore it is not the optimal color space as source for modern video codecs. This would also explain why the Indexer takes aged to build an index: It will write keyframe data for really every frame, because completely uncompressed video consists of keyframes everywhere. Such a video is hard to handle by L-SMASH Source. In this case only, AviSource is to be preferred.
|
I think it IS uncompressed, or barely compressed. It's a game footage captured with MSI Afterburner, using some lossless codec.
That doesn't seem to be the problem though - the problem is MeGUI using the same physical disk for processing the file, resulting in extreme slowdowns.
Quote:
Originally Posted by Zathor
As a starting point please create the index again (so the step which takes so long time) and then please upload the MeGUI log e.g. to pastebin.com. You can find the log in the MeGUI\Log folder (please close MeGUI before you export the log so that it is written in the correct way).
|
The file is gone, but I think I found the log.
http://www.mediafire.com/download/lm...9_17-09-53.log