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

[Michael Niedermayer]

On Sat, Mar 22, 2008 at 10:54:34PM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Mar 22, 2008 at 7:58 PM, Michael Niedermayer <michaelni at gmx.at>
> wrote:
> 
> > 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.
> 
> 
> Not every av_log() will be translated, that's insane. Most generally, all
> debug messages that users would normally not see will not be translated,
> because they are there for the developer more than for the user. If the
> developer needs a translation before he can "parse" the user's error output,
> it doesn't help at all for the user to read "error pts %lld < %lld
> non-linear" in his own language, because he doesn't know what a pts is. What
> you translate is those strings that convey useful information to the end
> user, such as an errno return value from a system call (e.g. "host not
> found" when reading a http stream). That is not 130kb.

130k was just a approximation. If you think that it was too far off.
Let me pick another approximation.
/usr/share/locale/de/LC_MESSAGES/xmms.mo has 67547 bytes
Thats the size of a what is really translated in a real application
so your argument fails.
Also its just an audio player, ffmpeg does alot more, one would expect
thus that ffmpeg would need at least twice of that.
But at that point we are at 70kb (the size being twice due to duplicated
strings)

So our first guess says 130k * 2 per laguage, the second one says
70k * 2 per language, these are quite similar and will not affect the
conclusion one has to draw from this.



> 
> Anyway, it's besides the point, because embedded systems will strip down
> both ffmpeg and the i18n'ed to fit whatever size their stick happens to be
> anyway. Your special gettext implementation will take additional binary
> space also (rather than using the system-default gettext), which probably
> already negates half of the gain.

the 2kb my gettext implementation might need is in no relation to gnu gettexts
size. So truth be they could safe alot more by not using gnu gettext.

> 
> I'm willing to do the work, but it has to be reasonable. Linux happens to
> have a standard for this kind of stuff, let's please use it.

If you want gnu gettext then you will have to fork. This is not something you
will get my agreement for.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Thouse who are best at talking, realize last or never when they are 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/20080323/8d76353a/attachment.pgp>