>I've noticed the FIXME in encode_x264.c/encode_xvid.c regarding the right
>place to set on vob->ex_v_codec, so I'd like to discuss this issue.
>
>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. How about redefining info.codecs_out[] so that the first
element in the array is considered the default output codec?
>I've some patches that implements this behaviour in transcode itself too.
>The only drawback is that -N option is no longer fully compatible with past
>releases since now it wants codec _names_, not ids (requesting ids it's
>feasible for audio codec, not for video ones, they have much longer and much
>more ids).
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". 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. (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.)
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
