Hi! Dominik wrote:
> I have a lot of free memory (3GB), but when I open a new .vdr file and > index it, the cache is not filled. (I'm using SUSE 10.2) Yep. This is not a Suse bug^H^H^Hfeature, just in case you wondered. > If the cache would be filled with the entire video (many movies or > series are less then 3 GB) the export of the video would be much faster, > because there's no need the read something from hard disk. It's just > writing from memory to hard disc. Correct, but: Most computers don't have enough RAM to hold a complete movie. Even at low (DVB-T) quality, we're talking about 1 GB/hour. DVB-C/S uses even higher bitrates, and HDTV will increase them further (think of Blu-ray Discs with a capacity of at least 25 GB). > Has anyone an idea why the cache is not filled during index generation? Because I told dvbcut to do so. :-) 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. -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------------------------- 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
