Mon Sep 25 19:53:10 CEST 2006
Andreas ?man wrote:
> Michael Niedermayer wrote:
>> On Sun, Sep 24, 2006 at 01:21:40PM +0200, Andreas ?man wrote:
>>> I've written a tentative patch that adds ID3v2. reading
>>> and ID3v2.4 writing to the mp3 (de)muxer. I've tested it
>>> together with xmms and itunes.
> [... snip input code...]
>> IMHO strings in ffmpeg should either be ASCII or UTF-8 but never
>> random like ISO-8859-1
> [... snip output code ...]
>> UTF8 should be default
> I definitely agree on this. But it rises some more questions which
> is a bit outside the scope of the id3v2-patch itself.
> The asf-parser just cuts away the top 8 bits from the 16-bit (UTF-16?)
> encoded strings. (Which currently works quite well together
> with the ISO-8859-1 encoding). And i bet there are more places
> where some more or less random string-conversion happens.
> So the iconv_() functions come in handy. But i dunno if it's
> is acceptable that ffmpeg depends on iconv?
> Perhaps adding a CONFIG_ICONV is the right way to go, and unless
> it's defined we stick to the current "random" string conversion.
I think it would be nice to have the option, but not mandatory.
> Should ffmpeg then use UTF-8 (or plain ASCII when compiled without
> iconv -support) internally?
That would be the solution with less code changes. I implemented that on
DrFFMPEG and translate the path to open in file.c to wide chars. It's
just one function to add.
We used to use iconv in DrDivX until we removed it in favour of the
built-in windows function and we gain 400 KB of code...
More information about the ffmpeg-devel