Hi!
Ralph Glasstetter wrote:
> Am Donnerstag, 4. Oktober 2007 09:02 schrieb Michael Riepe:
>
>>>> 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.
>
> Buit it's not working (with rev74) that way...
> ---> /dev/fd/63: not a regular file
Oh... no, of course it isn't.
>>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).
>
> OK, that's even better than the "-" (which I just used for historical
> reasons). But the ""-Argument will need the same special handling...
That should be as easy as
if (filenames.empty())
create_a_pipe_inbuffer(STDIN_FILENO);
else
create_a_multifile_inbuffer(filenames);
and (as opposed to the "-" solution) you only have to add it in a single
place.
[...]
>>I see... you're copying from one disk to another.
>
> Yes, always when possible... even when I'm cutting/authoring input/output is
> always on diferent disks... without that you'll loose another Faktor of about
> 2!
*nod*
>>>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.
>
> Yes, of course.. that's the reason why we gain in the end from using the
> pipe...
I got too used to fast disks and huge caches... ;-(
>>>The pipe:
>>>real 1m13.238s
>>>user 0m10.373s
>>>sys 0m18.805s
>>
>>29 seconds processing time - almost 50% overhead for the pipes.
>>Less waiting, though.
>
> yepp,... exactly! The 43sek waiting for I/O, is even more than a factor of
> 2... and this factor remains nearly the same with faster disks, just the
> absolute times decrease!
Not if the whole file fits into your RAM. ;-)
> OK,... when the disks are fast enough it doesn't matters anymore... but
> usually with faster disks you'll also have faster CPUs so processing time
> also decreases... and finally your demands will increase and you want to
> process 50GB-files instead 5GB-files and the problem is back... ;-)
What I really would like to have is multithreading. But I'm afraid
that's impossible with the current design of dvbcut.
>>>... 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.
>
> I also try to avoid it, but as I said... sometimes I don't have the time!
>
> And ever tried it when authoring the dvbcut output?
It's slightly slower then (where "slightly" is a factor that depends
mostly on your hardware).
> Input/output from the same disk costs always because of the repositioning of
> the read/write heads... the disks may be 3 times faster for sequential
> reading/writing but not in repositioning!
That's what caches were invented for. ;-) Of course performance will
decrease dramatically once the cache is full, but that's a different story.
>>Anyway... If you really need that feature,...
>
> What do I REALLY need...?
> OK, It would be nice... ;-)
>
>
>>... 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.
>
>
> I didn't wanted to bother you, that's why I tried to implement it by myself.
> And since it worked without changing much I didn't thought about providing a
> second providedata method... but maybe that's better in terms of
> maintainability!
At least your work will not be lost completely. I guess I can re-use
parts of your patch for the final implementation.
> On the other side reading from STDIN is per definition one file-mode,
Not exactly. With many Unix programs you may also mix files and stdin,
e.g. "cat a - b". But that won't work with dvbcut because the size of
stdin is unknown (using LLONG_MAX or another huge value doesn't work
either). You may get away with stdin as the last part, but I do not
consider that useful for dvbcut.
> which is
> just a special case of multi-file and I wouldn't want to separate
> single/multi-file mode...
Unfortunately, that's only true when you don't need mmap() and lseek() -
or connect stdin to a regular file (which wouldn't make much sense in
our case).
> but ok, since mmap/lseek is useless/not needed one
> could write a streamlined providedata just for STDIN...
Actually, my first idea was to provide a different kind (subclass) of
inbuffer. I'll have to examine the issue more closely, however. Maybe
there is a way to combine both if I modify the multi-file stuff a little.
--
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/dvbcut-devel
