Hi,

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 [...]

where
-N selects the export CODEC (format) to use
-y select the export MODULES to use (which in turn implements/provides codecs)

Rationale for this:
- allow to user to easily (and uniformly) select codec when using a module
  that provides more than format (ffmpeg)
- allows to core to check in a easier way compatibility between encode and
  multiplex modules (see tc_module_match in src/encoder.c::export_setup)
- in the long shot, will help us to implement fancy things like let the
  core automagically choose the "best" encoder module that provides
  a given 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). Anyway, I don't see this change as a Bad Thing since names are
more human-friendly that ids :)

Thoughts?

If noone objects nor suggest anything better I'll update CVS HEAD in the next
days.

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

Reply via email to