[FFmpeg-devel] Suggestion for a centralized language-tag facility in libavformat

cyril comparon cyril.comparon
Fri Apr 17 12:13:42 CEST 2009

Hi and thank you for your very complete tips.
However, being a developer myself, I still made the decisions I made
for the following reasons:
- no public dinstinction beween 639-2-B and 639-2-T: the main purpose
is to provide one pivotal code space that could be used as a
transition for every code-space conversion ; not two. I could have
gotten rid of 639-2-T but I still wanted to be able to convert from
- considering 639-2 codespace as a central codespace to convert
through, no need to write x*(x-1) conversion functions but only
- linear search: it hurts my eyes too but I've been told to optimize
the important code, not the peripheric one.
- there won't be lots more of standard codespaces to integrate. Even
the RFC1766 relies on 639-1 (plus an additional geographic marker).
- keeping things as simple as possible for the same result
I am pretty confident my argument is sound but I am not an
ffmpeg-developer so I'll let you with the final decision.

More information about the ffmpeg-devel mailing list