Hi,
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
>
> 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...
> > 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.
Didn't noticed any problems with multifile in gui-mode when going back and
forth through the video...
AFAICS the re-positioning when going forward is triggerd automatically by
while (seekpos >= i->end) {
++i;
assert(i != files.end());
needseek = true;
}
but now I'm not sure what happens if (seekpos < i->off)... in my test it
worked but maybe my (mulit)file snippets have been to small....?
> > 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.
That's why I didn't had to if(mapping){} that part (which was in fact my first
version)... ;-)
>
> >>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.
Of course,... that's why I wrote you and asked looking over the patch... :)
>
> 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!
> >
> > 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...
>
> > 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!
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... ;-)
>
> > ... 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?
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!
>
> 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!
On the other side reading from STDIN is per definition one file-mode, which is
just a special case of multi-file and I wouldn't want to separate
single/multi-file mode... but ok, since mmap/lseek is useless/not needed one
could write a streamlined providedata just for STDIN...
> Stay tuned,
As always... ;-)
ciao
Ralph
-------------------------------------------------------------------------
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
