Hi! Ralph Glasstetter wrote: > Hmmmm,... > I'm not quiet sure if you understood my points... ;-)
Of course I did. > Am Mittwoch, 3. Oktober 2007 23:39 schrieb Michael Riepe: > >>>tsfilter <INPUT.tts | tee OUTPUT.ts | dvbcut -generateidx -idx >>>OUTPUT.ts.idx - >>> >>>when I noticed that this isn't no more possible! :-( >> >>Not this way, at least. If you're using bash or ksh, you may try this one: >> >> dvbcut -generateidx -idx OUTPUT.ts.idx \ >> <(tsfilter <INPUT.tts | tee OUTPUT.ts) > > That's also only working dvbcut is capable of dealing with stdin, which is > now > triggered by suppling '-' as filename (which I've re-implemented). It's not an ordinary input redirection: The shell translates the whole "<(...)" construct to the name of a pseudo-file (e.g. "/dev/fd/42"), and that is passed as an argument on the command line. No need to deal with "-" and stdin. The "-" argument (and all its special handling) weren't needed in either case if we used clear semantics: If -generateidx is used AND there is no filename argument, THEN read from stdin and write the index to stdout (unless a filename is specified with -idx). [...] >>>The appendet patch now re-invents the 'wheel'... :) [...] >>>Actually there was just a small change necessay to inbuffer::open >>>and makeing 'needseek' (used in inbuffer::providedata) globally visible. >> >>Ugh. Did you try multi-file mode after patching? And, in particular, >>navigating back and forth between multiple input files? "needseek" was >>local (and initialized to "true") for a reason. > > It's still initialized to true if the file ist not '-'... if it is, we don't > need multifile mode and needseek... But it's no longer re-initialized when you jump between input files. That doesn't affect index generation (because it's reading sequentially), but GUI mode may go berzerk when you try to navigate inside a multi-file video. It requires re-positioning whenever the input file changes. >>>The rest is just cosmetics... >>> >>>Although, I'm not sure about the mmap-stuff in providedata (the part >>>which is not used under windows... maybe we can skip that also for STDIN >>>reading?). >> >>In general, neither mmap() nor lseek() works with standard input (unless >>stdin is a regular file - but then you could use it directly). But >>lseek() is required for both GUI mode (navigation) and multi-file >>support. Therefore, neither of them will work with stdin as the input. > > > Therefore the '-' is only possible with -generateidx... the mmap-call is > failing and does no further harm (as far as I could see), but one could also > skip this part as in the windows version in case of '-' (a 'bool > mapping=false' additionally to 'needseek=false'?). If mmap() fails, we fall back to an ordinary read anyway. >>Supporting stdin with -generateidx ain't easy either, and in my opinion >>it isn't worth the trouble it causes. > > Can't see any trouble,... Because you're not familiar with the design of the multi-file input layer and its special requirements. >>In particular since its advantages >>are close to non-existent. First of all, you still need exactly the same >>input file for cutting - that is, you have to write it to disk anyway. > > That's exactly what I want (and actually also sven when he implemented it the > first time... becaue I always wanted my disks back as fast as possible ;-)). > > >>Therefore the pipedversion doesn't save you any disk space compared to >> >> tsfilter <INPUT.tts >OUTPUT.ts >> dvbcut -generateidx OUTPUT.ts >> > > Disk space is not the point, it's time... > > On my disks (INPUT comes from a different disk than the output is written) > that's actually about a FACTOR OF 2!!! Huh? Unbelievable. How slow is your disk? > 99% goes into I/O and with the above command I have to read the huge file 2 > times and with the pipe just one time... the indexing in the pipe costs > nearly nothing (because the index file is small) > > Usually I have a SAT Receiver disk full of stuff... from time to time I'm > mounting it into my PC and have not always the time to cut the movies > directly from that disk because the disc is needed in the SAT receiver for > further recordings! I see... you're copying from one disk to another. > With the pipe I don't need the separate indexing step anymore, since it's > done > on-the-fly... don't have to think about it anymore or wait when opening the > file in dvbcut for cutting later! > > >>Besides that, dvbcut uses mmap() and a large read-ahead buffer when it >>processes a disk file (on Linux), making reads a lot faster than from a >>pipe that can transfer at most 64KB at a time. Not to mention all the >>time consuming context switches between the concurrent processes: >>tsfilter, tee and dvbcut. Pipes really are great as a concept, but their >>performance sucks if you have to transport some gazillion bytes. > > That's obviously not the case... > > 2 separate commands: > real 2m27.320s > user 0m8.817s > sys 0m11.309s That's 20 seconds processing time and 2:07 waiting for I/O. > The pipe: > real 1m13.238s > user 0m10.373s > sys 0m18.805s 29 seconds processing time - almost 50% overhead for the pipes. Less waiting, though. > ... processing a 1.3GB File (one of the disks is a rather old, therefore only > about 20MB/s ;-))! That explains a lot. My SATA disks are three times as fast, and I don't do the disk-to-disk copying thing either. Anyway... If you really need that feature, we need a cleaner solution for stdin. The multi-file inbuffer class isn't prepared for it (and probably never will be), so I guess I'll have to provide a second one. Stay tuned, -- Michael "Tired" Riepe <[EMAIL PROTECTED]> X-Tired: Each morning I get up I die a little ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ DVBCUT-devel mailing list DVBCUT-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dvbcut-devel
