Michael Riepe schrieb: > It doesn't make sense to cache a file that exceeds the size of your RAM. > Or half your RAM, for that matter. Caching is only effective when the > hit rate is high, i.e. when the same piece of data is accessed again and > again. And when there is enough room in the cache. Otherwise, you'll > have to write back and drop pages and perhaps re-read them later (an > effect known as "thrashing" - no, not "trashing" - which actually > reduces performance instead of increasing it). So, when your cache is > full and an application wants to read and write files, the system starts > thrashing badly. This is not what we want - remember that Unix/Linux is > a multi-user, multi-tasking system and that dvbcut may not be the only > application running. > > Therefore, we use a more environment-friendly approach: When dvbcut > generates the index or exports a file, it works in "sequential" mode > with a smaller amount of cache and more aggressive read-ahead. When you > navigate inside the file (random mode), MPEG data is cached as usual, > and there also is an extra application-level cache for decoded pictures. > > The drawback is that you need fast disks. For best results, you should > use two disks - one for the original file and one for the exported > video. I get export data rates of up to 50 MB/s that way, which is about > as fast as RAM-to-disk operation. If I export to the same disk, however, > the throughput decreases by more than 50% due to frequent read/write > head movements. > thanks for the explanation.
But, hmmm, I *have* enough memory to hold the complete movie in cache. (or think of 64-bit Linux with 8 GB RAM; 2GB costs only 37€! :-) ) Is it possible the make it customizable in the .qt/dvbcut.sf.netrc file? I thinking of: CacheVideoUpTo=2500MB (default value could be 1MB, just to show, that there's a functionality) Every video bigger than 2500MB is opend with sequential mode and smaller without that option (=everything in cache). This functionality would improve the export on same disk by 100% :-) (btw, where can I find the open file command to deactivate the sequential mode?) regards Dominik PS: yes, I know, a second disk would solve the problem. But the new functionality would also improve the performance when the second disk is faster that the first disk. PPS: Much better idea than the .qt/dvbcut.sf.netrc file: `cat /proc/meminfo` and calculate "MemFree+Cached-100MB (reserve :-) )": is the video bigger, than activate the sequential mode. If smaller, than cache the video! ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ DVBCUT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dvbcut-user
