Hi,
I'm thinking from quite long time how to handle in the most sane way
multiple input files (aka: 'directory mode, redesigned').
After a lot of thinking, I actually reached the conclusion that the better
way to handles multiples input file is to make things explicit and let
the core rotate input files much like it already does for output files.
* how things works now:
1) core gets an input source identifier
2) core passes such id to import modules
3) import modules behave 'intelligently' by detecting input source type
that means that if input source isn't a single file, but, say, a directory,
import modules WILL scan directory (without practical effective validation)
concatenating single input files. That's tccat will do.
* how things should work following my proposal
1) core gets *multiple* source identifiers and arrange them in a list or
something
2) core scan the whole input list passing each source to import modules
each import module does it's job dealing with a single source at once
3) when a single source ends (EOF), core get next in list, validate it
(i.e. verify that frame size/fps or channels/samplerate is the same,
or whatever is needed), then passes it to import modules
4) if input list ends, encoding ends.
Doing so will bring to us some improvements
- input layer (how we access to A/V content) is simplified since there is
much more or just none need to probe it *in import modules*, probing happens
only in core (and that's much saner way to go IMHO)
- we can verify that user doesn't (erroneously) do strange things like giving
as input a directory containing mixed content
- we DO NOT lost the ability to give in input multiple sources and let
transcode automatically do the right thing
- we DO NOT lost standalone tccat, it just will handle *single* sources
and no longer directories.
Of course, we also have some open issues in design and implementation
- we must reorganize input layer. Input layer take care of abstracting input
media (that's unexpected, isn't?) so upper layers doesn't care if their
encoded input data (say: mpeg2) come from dvd or from regular file or from
something else (another example: YUV420P data comes from v4l device, bktr
or regular file? that doesn't really matter since input layer omogeneize
things from input layer client's perspective)
Upper layers just read data from input layer and do their job.
tccat will still exist but merely acting to simple frontend to input layer.
new input layer will be arranged in a new support library:
NOW:
( tccat IS the input layer )
[ input layer: tccat ] +-> [ import module A... ]
+-> [ import module B... ]
`-> [ import module C... ]
FUTURE:
[ input layer ] +-> [ tccat ] (frontend)
+-> [ import module A...]
+-> [ import module B...]
`-> [ import module C...]
- we must reorganize probing code. To let the things work in most general case
(streaming source -> no seek allowed) core should probing source by opening
it ONCE, not TWICE like it does at present time (we can skip this? It's
just my paranoia?)
That basically means that probing code too should be rearranged in a library
used both by tcprobe and core (much like input layer above)
NOW:
( tcprobe IS the probing code )
[ probing code: tcprobe ] --> [ transcode core ]
FUTURE:
[ probing code ] +-> [ tcprobe ] (frontend)
`-> [ transcode core ]
- the last and the easier (to implement): we must take care of handling
multiple input sources. Even a lot of them (think to images->movie usecase)
that's the really usecase on which directory mode as is currently
implemented helps since at least we can easily running out of luck by using
long command lines (I'm thinking to
transcode -o foobar.avi -y xvid *.jpg).
A nice fit can be handle file glob internally, but the key point here is:
Should we change commandline?
current meaning of -i (and the whole existence of -i) founds on uniqueness
of input source.
Moreover, if we go on allowing more than input source, forcing the user
specifying a bunch of -i it's just clumsy IMHO, we should behave like
ffmpeg/mencoder: not-options argument is interpred as input file list.
NOW:
transcode -i something -y mod -o foobar.avi
FUTURE:
transcode -y mod -o foobar.avi something*
except for those interface issues, handling multiple source identifiers
it's a pretty straightforward and well-known task so it doesn't case much
worrying :)
Few, it was a pretty long and dense email, I hope content it's clear enough
and my english was understandable :)
Don't hesitate to flame^Wcomment and post thoughts, since from my point of
view the issues described here are one of bigger blockers for 1.1.0 release.
Best regards,
--
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!)
