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

Michael Niedermayer michaelni
Sat Apr 18 19:40:48 CEST 2009

On Sat, Apr 18, 2009 at 04:22:08PM +0200, cyril comparon wrote:
> Tell me if I am wrong but your idea might lead to the following issues :
> - less visually and memory-compact code table (n*p lines instead of n,
> extra offset attributes)

vissual compactness is a matter of how many \n you use
in terms of memory my suggestion should require less than yours, thats
because your table is 60% empty, and that would become worse where more
codesets added.

> - possible-but-hard to maintain and extend table (need for a common
> code-generator script)

    short *p=NULL, *init_p=NULL;
                *p= new_index[codeset];
            p= &new_table[ new_index[codeset] ].index;
            strcpy(new_table[ new_index[codeset]++ ].string, old_table[old_index][codeset]);
    *p= init_p - new_table;

    printf("{\"%s\", %d},\n", new_table[i].string, new_table[i].index);

above needs 2 passes so the placement of the codesets in new_table, that
is the initial new_index values are known

> - codespace-specific logics in the conversion function (if ISO639-T
> identical to 639-B then...)
> However, I don't mind giving it a shot (even though I keep quibbling
> about it), if I am absolutely sure that's the way you want it.

i want it fast, extendible, simple and compact.
If you have another suggestion iam not against another solution at all

> One more discussion may also be relevant to avoid future annoyance :
> what about code spaces that take localization into account (i.e. not
> only language), like RFC1766 ? As now, using my patch to demux-remux a
> wmv file containing, say, a "en-US" audio track would result in a file
> with an "en" audio track.

lang and country codes are 2 seperate things, we should eventually support
both, i guess your code could with a seperate and independant table be used
to remap country codes too, but here en-us would be split by the user to
"en" and "us" and both be passed to the 2 seperate converters, but then i
guess most use the more or less standard 2 letter country codes so maybe
we dont need any remapping for that yet

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090418/6230815e/attachment.pgp>

More information about the ffmpeg-devel mailing list