On Sun, 04 Jun 2006 16:41:15 JST
[EMAIL PROTECTED] (Andrew Church) wrote:
> Please, no! I spent so much time getting rid of the extension-adding
> code because it kept breaking my scripts. :( If the user wants .avi or
> .mpg or whatever on his filenames, let the user put it there himself. You
> never know, maybe some obscure app will only work with MPEG streams that
> have the extension ".bob"...
You're right, so I need to rethink a viable solution for extension-thing
in multiplexors. In facts the only big (real?) problem is the raw one.
> I agree here, and I was trying to think of a way to take care of
> things without adding a new function, but you'd end up having to have an
> if-block in every (de)mux function to see if the files were opened, so it
> looks like it'll be cleaner to add a new function instead.
Indeed. So let's add it. :)
> >- add int (*open)(TCModuleInstance *self,
> > const char *video_file, const char *audio_file);
> >/* or maybe s/video/primary/ s/audio/auxiliary/ ? */
> >
> >that open each given file if argument != NULL and returns -1 if error
> >(tc_log*()'in it) and N if succesfull, where N it's equal to open files)
>
> Hmm... I'd think it would be simpler to just pass a single filename,
> because usually you'll be using a different demuxer/muxer for the video and
> audio files if you keep them separate (e.g. mux_avi for video, mux_wav for
> audio). The core would create two (de)muxer instances, one for each
> separate file, and pass just the video frame or just the audio frame to the
> (de)mux routine as appropriate.
That's good for demuxers, but not so good for muxers. There is a couple of
issues:
1) encoder core code (src/encoder.c) uses single-instance multiplexor and
runs it, as well as A/V encoders, in a single thread. This happens both on
OMS and in NMS-powered code. I'm pretty satisfied of this situations because
it's work quite well, it's clean enough and... We need to join streams at
some point in processing pipeline!
2) From encoder point of view, the common case is the single-file output.
There are some notable exceptions (I'm thinking to -y ogg or to --export_prof
dvd -y ffmpeg) but they are caused mainly by a deficiency of existing code,
notably the lack of MPEG and OGG/OGM multiplexor than by a design decision
and/or a deliberate user choice.
For this reasons, I'd like to get stuck with double filename. Of course I've
no objections to switch to single-filename open() as well as we find a clean
way to feed a (de)multiplexor with both filenames avoiding tricks (i.e.
ALWAYS interpret first open() to video open, second one to audio open...
Rather nasty :\ ).
Maybe adding flags it's just the way to go?
typedef enum tcopenflags_ TCOpenFlags {
TC_OPEN_VIDEO = 1,
TC_OPEN_AUDIO = 2,
/* more to come if needed/useful */
};
/* -1 -> failure, tc_log*() reason; 0 -> succesfull (like open(2)) */
int (*open)(TCModuleInstance *self, const char *filename, TCOpenFlags flags);
Best regards,
--
Francesco Romani - Ikitt ['people always complain, no matther what you do']
IM contact: (email-me, I have antispam default deny!) icq://27-83-87-867
some known bugs: http://www.transcoding.org/cgi-bin/transcode?Bug_Showcase
