Hmmmm,...
I'm not quiet sure if you understood my points... ;-)
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).
So
dvbcut -generateidx -idx OUTPUT.ts.idx - \
<(tsfilter <INPUT.tts | tee OUTPUT.ts)
will work NOW (and is the same as my commandline above, or isn't it?)!
>
> > Doing some 'archeological excavations' I found out that this feature was
> > already lost in the pre-svn aera (official 0.5.3 was able to do this kind
> > of stuff) and the introduction of multifile input probabely wiped finally
> > away the last code remnants... code for writing the index to STDOUT
> > (without the -idx option) survived, but couldn't be used since the '-'
> > was not allowed anymore as filename)... ;-)
>
> Sorry for that. On the other hand, why would anybody want to write the
> index to stdout?
That's actually not the point... that was just left from svens old
implementation (I didn't wanted it to write to STDOUT)...
maybe there was no -idx switch that time and when the mpegfile was read
from STDIN he wrote the generated index file to STDOUT?
> The only program that can process it is dvbcut, and I'm
> pretty sure it never was able to *read* the index from stdin.
Of course,... not the index (that's useless), but it could read the mpeg file
form STDIN!!!
>
> > The appendet patch now re-invents the 'wheel'... :)
>
> That's not a good idea at all. Reading from stdin interferes with the
> multi-file capability, therefore you can't just use "-" as the filename,
> read from stdin and expect everything to work.
I don't expected it... but it does... of course, I had to handle that '-'
specially in the code...
>
> > 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...
>
> > 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'?).
>
> 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,...
> 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!!!
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!
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
The pipe:
real 1m13.238s
user 0m10.373s
sys 0m18.805s
... processing a 1.3GB File (one of the disks is a rather old, therefore only
about 20MB/s ;-))!
>
> > I also forbbitted the usage of '-' as filename not only when in gui mode
> > (which don't makes sense), but also when in batch-mode because it simply
> > don't works at the moment! Don't know why... actually it should,... at
> > least I've no idea why not... maybe you have?
>
> "-" does not automatically mean "stdin" - it usually needs special
> handling.
Of course,... as I wrote already... I specially handled it in the code!
At least for generating the index...and since I never wanted that feature to
work in batch mode I stopped at that point...
>
> [...]
>
> > PS: Ahhh... forgot to mention that with this patch it's also possible to
> > give -g/-i/-b as CLI switches.. or -gen/-ind/-bat... or whatever you
> > want... ;-)
>
> That has been possible before - I've been using it all the time.
Your right!!! I didn't was aware of that and didn't realize that the 'n' which
was given to strncmp is the length of the input switch allows also for
inputting just part of the switch...
The difference is with my solution -generator is a also recognized as
-generateidx,... so it's of course better to leave it as it was!!! :-))
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
