Odyssey 1.23 progress: r5 RC2

Total lamer suggestion, but can split the binary into a core and add on type set up?

try to enlarge the text section using something like -Ttext=2000000 to cflags/cppflags

@afxgroup
Quote:

For all the objects ? (that also mean recompiling of beast => one more day).

@afxgroup
Tried on one of objects (where -mlongcall make it works), and -Ttext=2000000 didn't help

@all
Found that in morphos build -mlongcall also in use. So, will rebuild everything with it now (damn!). Through, that mean 1.23 will be slower somewhere. Dunno when -mlongcall start to be in use , but till 1.17 there wasn't. But as Fab add it then its all expected, so one more day till binary done as whole recompile starts. But for sure with -mlongcall things going to be slower (google says same). As well as attaching that huge-fat ffmpeg libraries will make loading of binary slower, too, as binary will be bigger.

which cpu are you using? did you use the -j switch when compiling?

@afxgroup
Quote:
Of course all with -jX, it speed up things a little , but as i build it on cygwin on notebook which i just buy for some simple text work that just tells and speed pretty sucky. I thinking about build it on some of my remote linux servs, but repeat all the same steps now which i do in last days but on another serv pretty boring, so better just wait a day :)

cygwin has become too slow.. try with linux/mac and you will notice the differences..

@afxgroup
Yep, i already tested it with dopus5 : whole dopus5 builds on my cygwin for about 30 minutes i think. On dopus5.org serv (which is just some common linux with more or less ok cpu) , build whole dopus5 for about 7 minutes. That for os4 version, os3 version builds even faster. Its and cygwin slower in few times, and cpu differences make sense of course :)

@kas1e

Well, I didn't use the longcall option without reason. The executable got too large at some point, and it couldn't be avoided without annoying hacks.

That being said, you're not forced to make it even 50 MB larger than required by linking the whole ffmpeg libraries. Just build the decoders/formats/parsers in the HTML5 specification, it will take less than 5MB then.

For instance, using the following options would be a good start:
--arch=powerpc --cpu=powerpc --enable-runtime-cpudetect --disable-indevs --disable-protocols --enable-protocol=file --disable-network --disable-encoders --disable-decoders --disable-hwaccels --disable-muxers --disable-demuxers --disable-parsers --disable-bsfs --disable-devices --disable-filters --enable-decoder=aac --enable-decoder=aac_latm --enable-decoder=h264 --enable-decoder=mp3 --enable-decoder=theora --enable-decoder=vorbis --enable-demuxer=aac --enable-demuxer=aac_latm --enable-parser=aac --enable-parser=aac_latm --enable-demuxer=mp3 --enable-demuxer=mov --enable-demuxer=ogg --enable-parser=mpegaudio --enable-bsf=h264_mp4toannexb --enable-decoder=pcm --enable-decoder=wav --enable-demuxer=flv --enable-decoder=flv --enable-decoder=h263 --enable-decoder=vp8 --enable-demuxer=vp8 --enable-parser=vp8 --enable-decoder=vp9 --enable-demuxer=vp9 --enable-parser=vp9 --enable-bsf=aac_adtstoasc --enable-decoder=mpeg4 --enable-parser=mpeg4video --enable-demuxer=matroska)

Oh, and by the way, you probably won't even notice a difference between using longcall or not in an application like Odyssey. I didn't see any in benchmarks, at least.

@kas1e

Great work Kas1e! Keep going!

..and thanks!

Scott

@All
All rebulds, those errors gone, but now same errors happens in the libicu libaries (at first in the libicui18n.a):
Quote:

What mean need to rebuild all libicu libs now with same -mlongcall (and, i fear all the other libs i link with may need the same rebuild with -mlongcall in end..)

@Fab
Thanks for, it through bring few warnings:

Quote:

But all other options ok, builds fine and size of final ffmpeg libs now reduces pretty much:

libavcodec: full: 70mb , your: 20mb
libavdevice: full: 257kb, your: 80kb
libavfilter: full 6mb, your: 1mb
libavformat: full 28mb, your: 3mb
libavutil, libswresample and libswscale: mostly the same as with full build.

As for -lmlongcall, google still says that code with it bigger and as result slower, but if it make no visual differences for your tests, and other solutions is ugly hacks, then will just do as you do for mos.

@kas1e

latm is in 2.0 but perhaps it's been renamed. As for wav and pcm, there's so many options I can't tell you which ones to use.

I was going to say libvpx_vp8 and libvpx_vp9 but then I realised that's probably not the same as vp8 & vp9 without the libvpx prefix. There's probably internal decoders for it, and of course you'd want to use them to keep filesizes down and reduce the amount of dependencies.

@Mick
I use the latest ffmpeg snapshot (that one which we discuss with you week ago), which about the same as Fab use in 1.23, so i think the lines he post should works on version i have, just maybe something changes somewhere ..

Also libavcodec.a of 20mb is seems a bit big anyway.. Just want somehow to make it all in bounds of original mos binary (i.e. 50-60mb with mediaplayer), not something around 100mb :)

@Fab
Which version of icu libs you use for now ? I just checked icu downloads, and last one are 52.1 and size pretty fat as well. In 1.17 readme i see you do update to ICU 4.9.1 is it version you use now ? Also that "the data files are now stored externally in PROGDIR:resource/icudt49b/ to save some memory. Make sure to copy them if you update (a requester will warn you if you don't).", so it mean some specific changes in code of libicu too and if so, can you share them too ? I can of course build version 4.9.1 all statically, but binary will be again bigger then..

@kas1e

If you've got a binary from a previous build (where all internal demuxers/decoders are enabled), then you can use "ffmpeg -formats" (and -codecs / -decoders) to get a list of the proper names, and then you should be able to use them on the configure line.

To me this binary size question hangs on this: if displaying an image puts away RAM for as long as the browser is running, then the binary size needs to be as slim as possible.

Kas1e, your regular updates are great thanks!
How far along would you say you are in having a Release candidate?

@ddni

Well at the moment he is into a linking stage, it's too early to ask for

@Thematic
Binary should be small in any case, just for more or less fast loading: 50-60mb is already not small, but as far as i see morphos version of 1.23 with mediaplayer are 53mb of size, so should be 60mb max for os4 version.

@ddni
Need to deal with libicu now (and maybe some other libs will need rebuilding with mlongcall as well), as well as deal with ffmpeg to have it really 5mb of size, as well as deal with mediaplayer after binary will links and usuall os4 specific parts will be fixed.

@kas1e

You probably compiled ffmpeg with debug enabled (-g). That makes them way bigger.

About ICU, i still use 4.9.1. There's no reason to update, and it's so boring to build i prefer doing it as rarely as possible. If the data files are external, that's because there was some issue that prevented the big libicudata containing all data files from working properly (possibly a bigendian issue with their weird custom elf loader).
And since libicu is so smart that it crashes as soon as a datafile is missing, i had to check for every datafile. But this code is in Odyssey itself, not in ICU, so you don't need anything else.