[FFmpeg-devel] GSoC with FFMpeg waht a combination!
Sun Mar 23 00:58:04 CET 2008
On Sat, Mar 22, 2008 at 07:31:22PM -0400, Ronald S. Bultje wrote:
> On Sat, Mar 22, 2008 at 7:19 PM, Michael Niedermayer <michaelni at gmx.at>
> > On Sun, Mar 23, 2008 at 12:33:04AM +0200, Uoti Urpala wrote:
> > > On Sat, 2008-03-22 at 13:29 +0100, Michael Niedermayer wrote:
> > > > On Sat, Mar 22, 2008 at 12:37:39AM -0400, Ronald S. Bultje wrote:
> > > > > Will you accept patches that add internationalization-support to
> > > > > ffmpeg/lav*?
> > > > >
> > > > > It's high on my fairy-list.
> > > >
> > > > Sure just keep in mind that you will be flamed if this is done with
> > gettext :)
> > > > The reason being
> > > > * gettext duplicates english strings all over the place
> > >
> > > I'm not sure exactly what gettext duplicates, but how much space would
> > > this waste? It'd need to have many copies of every string to make a
> > > difference for FFmpeg.
> > I would estimate that gettext needs roughly twice as much disk space as a
> > integer based system and about 3 times as much in memory
> > (english string in _() and as key as well as the translated string)
> > The disk space matters only for embeded systems of course. There it can
> > matter a lot though, especially with few codecs and many languages.
> As you no doubt know, embedded systems ship only a few languages, i.e. those
> within the region in which that particular regionalized version of the
> product is sold. For the same reasons, your DVD player did not ship with a
> Thai, Greek or Tunesian manual, but only a German and an English one.
With a hashtable based system instead of strings as keys they could contain
twice as many laguages.
And i think there are plenty people from distant places living in germany
who might be happy with a localized embeded system which contains their
> Shipping is easy, you simply pick the .po/.gmo files that you want.
> As for the .gmo file size, why don't you fix gettext() upstream?
If we implement a better system i certainly could propose that to them.
Its hard to do this before we have anything.
> I suppose
> it's the same reason you're not fixing upstream gcc, libc, etc.?
The problem here is lack of time.
> Please, be
> reasonable. If this were for a pixel operation, I'd agree, but this is for
> UI strings, it's not at all performance-critical.
The memory this needs is the same memory the pixel operations use. And that
is limited on embeded systems
strings ffmpeg | grep '[a-z][a-z][a-z][a-z][a-z]'|wc -c
130kb is not that little for an embeded system, gettext would need
twice that for each additional language in addition to the 130kb english
With 5 languages thats 1.3mb, this is 1/4 of ffmpegs size. This _does_
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
More information about the ffmpeg-devel