Xcode and iPhone simulator: The application won’t launch

This is another migration issue from iOS 3.x to iOS 4.x projects.

The application does not launch in XCode when running Simulator – Debug. Instead it dies (SIGABRT) before entering main().

#0     0x91a02ef6 in __kill
#1     0x91a02ee8 in kill$UNIX2003
#2     0x91a9562d in raise
#3     0x91aab6e4 in abort
#4     0x0245e8c9 in __springboard_unimplemented
#5     0x0246d6b2 in mcount
#6     0x00002298 in main at main.m:11

The answer lies here. mcount() function is profiling function. Profiling is available only on iPhone device build. The setting “Generate Profile Code” somehow gets into foobar state when you migrate the project from older XCode. Note the setting is present under both Project and Target settings so you might need to fix it under the both sections.

Read our blog  Subscribe mFabrik blog in a reader Follow us on Twitter Mikko Ohtamaa on LinkedIn

Python 2.3, Python for Series 60 1.4.5 still in use… and insight into Symbian deployment process and user experience

Nokia’s Python for Series 60 has a long history. It is a Python interpreter, originally escaped from Nokia prototype labs, running in your phone. It is said to been awesome to show mobile/embedded developers, who were love with their static C compilers and 4 hours built times, opening a Python prompt in your phone and typing import audio; audio.say(“your phone loves Python”) by keypad (Nokia Series 60 phones come with a speech synthetizer). Python for Series 60 is the best tool of building a simple proof of concept mobile applications. The lack of speed, lack of good UI libraries and difficult deployment problems makes it challenging to use it in production grade environments.

PyS60 has also a history of staying in archaid Python version – namely Python 2.3. It was not until this February when stable PyS60 2.0.0 with Python 2.5 was released (1.9.x was considered experimental according to the release notes). Luckily looks like new winds are blowing (Qt acquisition, Meego/Maemo) and Python is getting higher priority. For example, PySide Qt bindings is very high profile project. Based on this, we hope to expect Python to the first class citizen in the future Meego and Symbian devices.

My company had a little side venture with PyS60 Community Edition when we were still betting that Symbian and Python would rock the world – the era before iPhone changed the game.  PyS60 community edition was effectively a revamped PyS60 1.4.x with Python 2.3 toolchain which actually made PyS60 application production deployment possible. Possible…? -you ask. Madness… no. It is Symbian. It is certification and signing and obscure error messages. Basically vanilla PyS60 is being shipped as an external SIS (Symbian package format) and Symbian platform security makes it impossible to deploy two production signed applications using vanilla PyS60 on the same device. The only cure was statically building Python for both apps from the scratch, which is exactly what PyS60 Community Edition was doing.

But this all was long long time ago. Aeons in mobile time. So I was today surprised when I got email from a person (David) using PyS60 Community Edition. We never upgraded PyS60 Community Edition to Python 2.5 . In fact we haven’t touched the project about two years. David was effectively using Python 2.3 and asked questions about the tool chain internals.

My first answer was a question Why on Earth you are still using Python 2.3? I thought maybe the guy had somehow missed the last two years or was a stuck with an old phone.

However… this was not the case and the answer was very insigtful.

Yes, I’m aware of PyS60 2.0.0, but I prefer PythonCommunity, at least for the moment: no OpenC neither Platform Services dependencies; smaller .SIS size and memory footprint. I think that the final .SIS produced with PythonCommunity, with everything necessary to run contained in it and with a clean installation without multiple dependencies, is a better fit for a mass-market than the files produced by PyS60 2.0.0, above all taking into account that people don’t know what S60 or Symbian are.

Also, the runtime deployment on the new PyS60 isn’t automatic for S60_3rd and S60_FP1 devices, so in the worst case scenario, users may end having to learn to install the different files (pips.sis, ssl.sis, stdioserver.sis, Python_2.0.0.sis, PythonScriptShell_2.0.0.sis) in the correct order, which is a big no-no for a mass-market deployment.

So…. I hope someone in Nokia is reading this blog entry carefully. Do it like Apple does. Make your application deployment static. Make OpenC static. Make every freaking library which is not shipped with the device statically buildable. It should be possible now when everything is open source. It will consume precious device RAM, but at least it will make mass market application development possible. SIS hell is worse hell than deb hell, or DLL hell, as the end user cannot fix it due to device security.

In the related news SIS smart installer was announced few weeks ago. Personally I wouldn’t bet it can deal with all the problems of versioning and Symbian platform security. Forum reports aren’t promising and looks like very Symbianish user experience can be expected. In positive light, it seems that Python is being considered for this process.

Read our blog  Subscribe mFabrik blog in a reader Follow us on Twitter Mikko Ohtamaa on LinkedIn

How to encode h264 video files for Nokia Series 60 standalone playback

Bored with Spiderman 3 which came with your Nokia N95 8 GB? This guide shortly tells how to get movies into your N95 on Ubuntu Linux using ffmpeg video encoder. The aim is to encode video suitable for playback from Nokia N-series (N95, N78, others) mobile phone memory card. We use h264 + AAC codecs which provides the best quality/compression rate for Nokia phones currently.

Ubuntu does not distribute proprietary codes. First thing you need to do is to rebuild ffmpeg.  Since Ubuntu 8.04 Hardy Heron ships with ffmpeg from 2007, which is aeons old in video codec years, you need to build libx264 and ffmpeg from SVN sources. Here are detailed, valid, instructions. Note that FFMPEG trunk is not currently stable (September 2008), so you need to use revision 15261 which needs this little patch. Indeed, this is a very difficult month to start your career in the dark world of video encoders.

To make it legal and support open source codec development,  please pay for your codecs.

Then we use this guide by Robert Swain. We have a tiny sub 2,4″ screen, we do not care about the quality and do one pass encoding. By empirical research, I have found that the following MPEG-4 profile parameters are compatible with N95 8 GB and provide the optimal result. You can vary video and audio bitrate depending on your taste.

Here is a script which recursivelu encodes all detected video files suitable for mobile format:

#!/bin/sh
#
# Optimal movie encoding for Nokia N-series mobile phones
#
# Copyright 2008 Red Innovation Ltd.
#
# Say hi if you find this useful.
# We do some professional mobile video publishing, so if you
# need a helping hand please call us.
#
# Usage: Run encode.sh in any folder and all video files are recursively converted to mobile phone suitable format
#
# Note: We expect all the source material be in 16:9 aspect ration
#
# Also see http://www.nseries.com/index.html#l=support,search,faq,general,video%20encoding,53848
#

VIDEO_BITRATE=300k

AUDIO_BITRATE=72k

# Assume locally build ffmpeg + x264 in /usr/local/bin
# http://ubuntuforums.org/showthread.php?t=786095
export LD_LIBRARY_PATH=/usr/local/lib

# Search all source AVI, MPG and WMV video files
# Place all encoded files to the same folder with the source, with added .mp4 extension
find . -iname "*.avi" -or -iname "*.wmv" -or -iname "*.mpg" | while read src ; do
        srcfile=`basename "$src"`
	srcfolder=`dirname "$src"`
	dstfile="$srcfolder"/"$srcfile".mp4

	# The magical string!
	# Size and cropping is for 16:9 source material, so that 320:240 display will have black bars.
	# Fex pixels off... note that h264 sizes must be multiplies of 16, use 256x144 for streaming
	# N95 RealMedia player does not seem to respect MPEG-4 embedded aspect ration info.
	/usr/local/bin/ffmpeg -y -i "$srcfile" -acodec libfaac -ab $AUDIO_BITRATE -s 320x176 -aspect 16:9 -vcodec libx264 -b $VIDEO_BITRATE -qcomp 0.6 -qmin 16 -qmax 51 -qdiff 4 -flags +loop -cmp +chroma -subq 7 -refs 6 -g 250 -keyint_min 25 -rc_eq 'blurCplx^(1-qComp)' -sc_threshold 40 -me_range 12 -i_qfactor 0.71 -directpred 3 "$dstfile"

done