From XiphWiki
Revision as of 06:09, 9 November 2013 by Brion (talk | contribs)
Jump to navigation Jump to search

At least libogg, libvorbis, and libtheora build and run on iOS without modification in their current incarnations.


Experimental work in progress script to build the libraries to .framework bundles that can be easily linked to in an Xcode project:


  • uses existing autoconf build infrastructure; scripts wrap with appropriate settings, then combine into framework bundles
  • framework bundles each contain a 'fat binary' library with armv7, armv7s, arm64 for devices and i386, x86_64 for simulator, plus a subdirectory with the C headers
  • libtheora
    • Must pass --disable-asm, as the asm code doesn't build for iOS (yet?) errs


See preliminary benchmarks at

OS integration

Native codecs


iOS's native media framework is AVFoundation, which unfortunately is not extensible with codec or file type plugins. :(

It should be possible for an Obj-C wrapper library to use the same audio and video buffer types for input/output as AVFoundation does, however, which will make it easier to hook them up together for transcoding or live encoding from the camera.

File type handler


It is possible for an app that plays Ogg media to register its file types with the system, allowing other apps that may download files (Safari, Mail, Dropbox, etc) to prompt to open them in the player.

I have implemented an early test of this in OgvKit demo player; it works but, for instance Safari will download the entire file and then hand it off to the player, so you cannot play during the download.

URL handler


It is possible for an app that plays Ogg media to register a URL handler, which would allow other apps or web content to launch the player. A remote URL could be included as a parameter on that URL, allowing apps or web content to hand off something to download-and-play progressively.

Unfortunately you can't do something like register for 'http[s]://*/*.ogv' -- you can only register a scheme such as 'x-ogvkit-player'. So you can't accept arbitrary HTTP or HTTPS links; the calling app or web content needs to know your app-specific URL scheme.

Related projects