On Sun, 11 Jun 2006 17:14:11 JST [EMAIL PROTECTED] (Andrew Church) wrote: [...] > >In tcexport (which is main testing field for NMS export layer) the solution > >adopted for this problem is to slightly modify the meaning of option -N. > >User must provide the wanted export audio/video format using something like > > > >tcexport -N xvid,mp3 -y xvid,mp3lame,avi [...] > > Hmm, this seems like a decent plan (and I guess you could then use -n > to override the autodetected input codec). But it would still be nice to > allow the encoder module to set a default value--after all, most modules > only support one format, and making the user specify it anyway is > confusing.
Yes, one codec per module is supposed to be the common case. FFmpeg is indeed THE exception ;) > How about redefining info.codecs_out[] so that the first > element in the array is considered the default output codec? That's quite nice. The only drawback is that requires some changes at capability match code, but isn't a big problem since I already planned a review/update/refactoring of such code. One of biggest motivations to change (extend) the -N behaviour was the following: >From my own point of view, in the mean case user want to select a _export format_ not an export module. So, given format, core should be able to automagically load an appropriate module. This isn't yet avalaible, but chianging -N is a step on this direction. Of course, for debug purposes or just in order to allow fine tuning, it will be also possible to select a specific export modules (as well as an import one, as we already do when overriding autodetection), but I'd like to make -y an "advanced" option. > There are two easy solutions for this: (1) use the old behavior if the > option is a valid integer, else the new behavior; or (2) use the new > behavior if the option contains a comma, else the old behavior. Of these > I'd prefer (1) because it allows you to say "-N h264" instead of having to > use "-N h264,auto". I've already commit'd some preliminar works for this, anyway implementing (1) (which I like more too) it's pretty straightforward, so I'll do ASAP. > You could also save the raw option string and then > parse it after all options are read and you know whether you have the old > or new -y format, but I don't like splitting the processing into two parts > like that. I'm not enthusiast too doing this way, even sometimes it's just needed :) > (Though it wouldn't be so bad if _all_ options were processed > after they had all been read in first... I guess that's something to think > about for when we rewrite transcode.c.) Indeed. +++ A word on transcode.c, since it was summoned^Wmentioned. Maybe it's not so scary, I've noticed some redundancy and repetitions on it. Anyway, it's still one of most scary pieces of legacy code that we have, IMHO. 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
