thefoundationhttp://www.thefoundation.de2010-07-01T22:53:07Z(c) 2012 Michael Kurze, Aachen, GermanyQuickTime Reference Movies in Python2010-07-01T22:53:07ZDavid Murmannhttp://www.thefoundation.de/about/davidquicktime-reference-movies-python<p>HTML5 video is on its way, and Apple likes to use reference movies to send different versions of movies to different clients. So, how do you generate these if you don't have OSX handy (for example on a server)? </p><p>This is pretty much the premise of a little tool I wrote to generate QuickTime reference movies. It is written in Python, because it is to be used in a Django app that handles video uploads and encodes. Well, that and because I <em>love</em> Python! There isn't much else to say, so here is the code if you are interested:</p> <p><code class="block">hg clone http://bitbucket.org/dmurmann/root pyqtref</code></p> <p class="annotation notice center">This is very much alpha software, it may fail horribly for you!</p> <p>The simplest possible example, generating a reference movie to 'content.mov' looks like this:</p> <p><code class="block">from pyqtref import * ref_mov = Movie(ReferenceMovie(Descriptor( DataReference('content.mov')))).to_bytes()</code></p> <p>The boilerplate is necessary, because the API is pretty close to the <a href="http://developer.apple.com/mac/library/documentation/QuickTime/QTFF/QTFFChap2/qtff2.html#//apple_ref/doc/uid/TP40000939-CH204-25756">Quicktime File Format Specification</a>.</p> Thoughts on the Android2010-03-24T13:45:36ZMichael Kurzehttp://www.thefoundation.de/about/michaelthoughts-on-android-platform<p>Nearly finished with an Android app that some fellow students and myself did for the mobile lab at RWTH University (simple foursquare like thing: maps, contacts, web services...). I am going to collect some of things that I liked about the Android platform and stuff that annoyed me when working with it.</p><p> First of all, let&#x2019;s state that it was fairly easy to get our application up and running. There were simply no Android problems that were too obscure or too complicated to deal with. Compared to the intricate hells of other Java environments, such as J2EE (think class loaders, think various closed source implementations...) I&#x2019;d say it was an easy ride for the most part. </p> <h3> The good parts </h3> <p> There was some stuff I really liked, plus everything to do with performance, as they obviously really thought about that, compared to say, SUN when they introduced their first JVM. </p> <ul> <li> <h4> generated resource identifiers </h4> <p> No need to mess around with strings in order to access resources. For each resource (localized string, layout component id, image) you define it in an XML file and an ID (as a public static final int) is generated for you. Yields performance benefits and some compile time safety. </p> </li> <li> <h4> eclipse integration </h4> <p> The android SDK does <em>not</em> depend on using eclipse, which is great if you like to learn what&#x2019;s actually going on and you know your way around with the shell. But today&#x2019;s developers are usually bred with eclipse support built right in (kiddin&#x2019;), so the eclipse plugin really helps as it calls the tools for you (e.g. to regenerate resource identifiers) so you don&#x2019;t forget. </p> </li> <li> <h4> layout tools </h4> <p> compared to the Interface Builder for iPhone, the XML based layout definitions need to allow for more flexible layouts, as android apps are not tailored to a specific screen size or orientation. They do a fairly good job of this, and whenever you are not satisfied you can simply define overriding layouts for specific devices or screen dimensions. The layouts do also have an advantage over CSS based layouts (Palm Pre) because you can easily fill horizontally or vertically or align to the bottom of the screen (that is just annoying with CSS). </p> </li> <li> <h4> The API&#x2019;s </h4> <p> Batteries are included: There is JSON support, various UI components, the mature HTTP libraries from apache commons, and everything from the good old JavaSE that is really useful. the awesome <a href="http://developer.android.com/reference/android/webkit/WebView.html" title="Android WebView documentation">webview</a> lets JavaScript running inside the view interact with your Java code really well! </p> </li> </ul> <h3> The bad parts </h3> <ul> <li> <h4> The API&#x2019;s: JSON </h4> <p> Yes, again. Some of the API&#x2019;s seem to me like they had to freeze them in a hurry. The JSON api is only <em>similar</em> the one you get from <a href="http://www.json.org" title="JSON Website">json.org</a> (an older, incompatible version). We wanted our serialization layer to live in a separate project from the android client, so I actually had to get the JSON sources from the Android source repository to downgrade our non-Android implementation to use the platform library.<br> The platform developers should offer standalone packages of all included 3rd party libraries they include, <em>in the version that got shipped with Android</em>. </p> </li> <li> <h4> The API&#x2019;s: Google Maps </h4>Compared to the awesome JavaScript API that you can use when you embed Google Maps into a webapp (or a Palm Pre app), the Android Maps API is just tiny. We wanted to set draggable markers and to reverse <a href="http://en.wikipedia.org/wiki/Geocoding" title="Wikipedia: Geocoding">geocode</a> the selected location, and we just used an android WebView and embedded an GMaps from a web site of ours. That is a tiny bit slower, but so much more powerful to just <abbr title="get things done">GTD</abbr>. While doing that I noticed again, how quickly you can get stuff going with just JavaScript and browser refresh compared to Java&#x2019;s holy "compile, deploy, navigate to screen" trinity of UI development. </li> <li> <h4> The API&#x2019;s: HTTP </h4>Honestly, I could not believe that there was no simple callback based HTTP abstraction layer over apache commons. Have you guys learned nothing from the success of AJAX? I mean, being with Google, they probably should have, but anyway: It is much too painful to access web services. We had to write our own layer for that (and no, I don&#x2019;t want to go all SOAP or even WSDL, I just want to get some lists or some image from our server...), instantiating thread pools, managing listeners and such. Perhaps I should use a WebView for that too, it can do that, you know... </li> <li> <h4> Internationalization </h4> <p> Perhaps I missed something there, but I18N can get really messy because a missing translation will cause no errors before runtime. This would ideally have a spreadsheet based editor or something like that, so you spot missing translations right away. Also, there are still some API&#x2019;s (<a href="http://developer.android.com/reference/android/app/ProgressDialog.html#setMessage%28java.lang.CharSequence%29" title="ProgressDialog.setMessage">ProgressDialog.setMessage</a>) that take strings where numeric identifiers should be used. Not sure about the reason, but this can lead to untranslated UI quickly (and did in our case...). </p> </li> <li> <h4> The date and time pickers </h4> <p> This is mainly about the usability. Compared to the iPhone, these simply sucks. The rolling barrels that the iPhone uses are probably patented, but it must be possible to make something that works more quickly than this. </p> </li> </ul> <p> All in all it was interesting to work with android. I must look into JSON serialization some more, as the various automatic available Java libraries (gson, json-simple, XStream, Jackson) that I glanced at when the json.org one annoyed me all seemed to have serious disadvantages, such as requiring change your model, to write lots of glue code, or to work badly with object graphs containing cycles. But that is another topic, for another time. </p> Streaming from iTunes to the iPhone: A Sketch2008-10-20T01:18:12ZMichael Kurzehttp://www.thefoundation.de/about/michaelstream-audio-itunes-iphone<p>Wireless playback of your music collection from iTunes to your stereo equipment, using the iPhone instead of cables or an AirPort Express. Requires a Mac, an iPhone, the Apple Developer tools and Fink, and the power to use them all.</p><p> I own an <a href="http://www.apple.com/airportexpress/" title="Apple &ndash; AirPort Express product page">AirPort Express</a> wireless access point that I used to stream my iTunes music to, so that it would play on the stereo equipment. In my current home though, my stereo sits in a corner, where an airport unit would cover my room but never the whole apartment. Also, I would have to pull an ethernet cable into my room for wireless internet access. So I put the airport unit into the hall instead. </p> <p> Before the App Store launched, I used to run a simple web service on my notebook. Written in Python, it would report the currently playing iTunes track using <a href="http://appscript.sourceforge.net/" title="appscript Project Page">Python &mdash; AppleScript</a> bindings. The iPhone would load a page containing an iframe for the actual audio resource (the HTML 5 audio support is not yet available on the iPhone) and an poll for song updates via XMLHttpRequest. This solution worked so-so, as there was a pause between tracks because the iPhone browser had to bring up the Quicktime plugin in a slow animation for each track, before even preloading the actual song file. </p> <p> Fortunately, <a href="http://www.sourcemac.com/" title="Website of Julien-Pierre Avérous">Julien-Pierre Avérous</a> offers his web radio streaming client <a href="http://www.sourcemac.com/?page=fstream" title="FStream WebRadio listener/recorder software">FStream</a> at the App Store for free! What's left to do now, is turning iTunes into a web radio station using free components: </p> <ul> <li><a href="http://jackaudio.org/" title="Jack Audio project page">Jack Audio Connection Kit</a> to rewire the iTunes output to a stream encoder</li> <li><a href="http://darkice.tyrell.hu/" title="DarkIce live audio streamer">DarkIce</a> to create an MP3 stream that can be fed to a streaming web server. You will also need to get <a href="http://lame.sourceforge.net/" title="LAME MP3 Encoder">lame</a> using Fink.</li> <li><a href="http://www.icecast.org/" title="IceCast project page">IceCast 2</a> as the actual streaming server. I had to switch to Fink unstable to get this version.</li> </ul> Next thing is to configure these tools to play along, which I shall describe in a follow-up article for the patient.