Hi,
The directory mode has some long-standing bugs (just take a peek at
transcode-users and/or at dvdrip-users archives).
I consider this issue a blocker for 1.1.0 release and I think there is room
and chance for a serious redesign of the whole code and idea underneath.
So, let's begin.
1. The Idea behind, plain and simple.
-------------------------------------
directory input mode allow user to specify a directory with multiple files
filled in and transcode all of them in a single step.
This is a nice feature, IMHO, so it should stay.
2. A couple of question left unanswered.
----------------------------------------
1) should files in the input directory have identical containers?
i.e.: all AVIs, all VOBs
we must choke an error if directory contains different kinds of file?
we must just ignore them? How we choose file to ignore and file to process?
2) should files in the input directory have identical stream properties?
i.e.: all identical video (WxH, fps,...) and audio parameters (rate,
chans...)?
same as above, we dinamically adapt all files to a common format or we
must just skip non-conforming files?
3. Possible answers.
--------------------
While thinking to various possibilities, I've reached the conclusion that
only TWO behaviours are sane, for my taste:
extreme case 1:
REQUIRE that ALL files contained in input directory have identical container
and stream properties.
extreme case 2:
ADAPT ALL files contained in input directory to a common format specified
by user using the command line.
I see way #2 significantly more painful that #1 given current import layer
architecture. Anyway, that can be really cool to do so. Maybe stuff for longer
term.
4. Implementation issues.
-------------------------
Current implementation skip almost enterely above issues. Actual code less or
more just read sequentially all files in given input directory. There also
are a couple of nasty bugs, despite my past effort to improve situation.
I think it's time for a more radical solution.
5. Designing future implementation
----------------------------------
We have two main ways to follow here
a) bury directory input handling into input layer, as we already do.
just rewrite it smarter and better.
b) rewrite transcode core to explictely handle *input* file rotation,
much like we already have for *output* file rotation.
Well, we already really have a sort of input layer, which take care of
abstracting different media sources: tccat. But the need for a better
encapsulation and organization of such layer is raising.
Following way a) lead us to unavoidable code duplication, since code
which effectively rotate input always needs to inspect file properties
to work properly. Any design that make some sense needs to known which
file type is handling at given time.
Moreover, I don't see some clear advantages doing a) way. Extensive changes
are always needed, and b) way looks cleaner to me, in the long shoot too.
Anyway, I'm still very open to discussion on this topic.
6. About tccat destiny
----------------------
Rearranging code in order to follow b) way DOES NOT MEAN AT ALL that tccat
will go away. tccat should be reorganized to become merely a front-end of
an another auxiliary library (libtcinput?) that will take care of allowing
transparent access to a *single* media source at time (plain file, network
(?), dvd, whenever you want...). Just rotation code will be split up and moved
into core.
7. Let's summarize
------------------
Time constraints, import layer design and actual probing infrastructure force
us to a trade-off. One of biggest problems is that current probing is done
using a separate process, so input source
1) is open'd twice
2) is seek'd
(in the worst case)
and that forces serious constraints. In order to make things cleaner, a deep
rewrite of the whole import layer is needed, and we cannot accomplish this for
1.1.0 (and neither for 1.2.0 I guess. It's a pretty long road).
So,
8. What I like to do
--------------------
Short version: 2b (see above).
Longer version:
1) drop directory support from tccat.
2) rearrange input abstraction in libtcinput, porting tccat to it. libtcinput
will deal only with *single* sources
3) handle input rotation file into transcode core, much like we already do
for output files.
4) require that input directory will contain files identical both in container
and stream properties.
I don't see practical regressions respect to 1.0.x, and I think doing so
will allow us to do more fancy (and cleaner) things in the long term
Thanks for reading so long, don't hesitate to ask if I've been unclear.
Any comment is welcome.
Bests,
--
Francesco Romani - Ikitt ['people always complain, no matther what you do']
IM contact : (email first, Antispam default deny!) icq://27-83-87-867
known bugs : http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase
tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!)
