[FFmpeg-devel] GSoC with FFMpeg waht a combination!

[Michael Niedermayer]

On Sat, Mar 22, 2008 at 07:31:22PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Mar 22, 2008 at 7:19 PM, Michael Niedermayer <michaelni at gmx.at>
> wrote:
> 
> > 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
language.


> 
> 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
says
129897

130kb is not that little for an embeded system, gettext would need 
twice that for each additional language in addition to the 130kb english
strings.

With 5 languages thats 1.3mb, this is 1/4 of ffmpegs size. This _does_
matter.

[...]

-- 
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
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080323/86c6641c/attachment.pgp>