Monday, July 23, 2012

Definitive Guide to Using Hyperdeck Shuttle II with Mac OSX

It took quite some experimentation and I was about to give up on this, but it looks I cracked it. I can now record compressed video with the BlackMagic Hyperdeck Shuttle II and use the video file with Mac OSX. I was already able to use the uncompressed video files from the device, but those are just too freaking huge to comfortably work with on a macbook air.

Make sure you are using the latest drivers and firmware as posted on the support page of Blackmagic design. I used the 3.0.2 version.

Set the device to record compressed files into a quicktime container.

Don't try to record output from your iPhone... I tried, and it did not work. My iPad2 and iPad3 HDMI signals were accepted just fine. You will need an adapter from Apple to hookup an iPad to a Hyperdeck Shuttle II.

BlackMagic wants you to install the DNxHD codecs from Avid's website. Frankly: don't bother. You can try, but they did not work for me. I would either get a black screen video with some audio (iPhone recording) or worse, I would have a crashing quicktime player (iPad recording). The crash I am seeing is this one:

Thread 3 Crashed:: Dispatch queue:
0 0x00007fff841595a7 _AT_AudioUnitUninitialize + 55
1 0x00007fff841ed819 MixerChannel::Uninitialize() + 27
2 0x00007fff841ede5e SubmixGraph::ConnectToDestination(bool, CAStreamBasicDescription const&, CAAudioChannelLayout*) + 184
3 0x00007fff841e7120 MasterMixer::ConnectSubgraph(SubmixGraph*) + 686
4 0x00007fff841e7415 SubmixGraph::ConnectInputChannel(bool, MixerChannel*, bool) + 657
5 0x00007fff841e7826 AQMEDevice::AddRunningClient(AQIONodeClient&, bool) + 262
6 0x00007fff841cbaf5 AudioQueueObject::StartRunning(AQIONode*) + 51
7 0x00007fff841c47e3 AudioQueueObject::_Start(XAudioTimeStamp const&) + 637
8 0x00007fff841c494a AudioQueueObject::Start(XAudioTimeStamp const&) + 18
9 0x00007fff841dd8cb AQServer_Start + 64
10 0x00007fff841e0e88 AudioQueueStart + 183
11         0x00007fff877497d8 FigAudioQueueStart + 551
12         0x00007fff877a33b3 0x7fff87728000 + 504755
13         0x00007fff8779ae4e 0x7fff87728000 + 470606
14         0x00007fff8779e2e0 0x7fff87728000 + 484064
15         0x00007fff8779e508 0x7fff87728000 + 484616
16         0x00007fff8779e75a 0x7fff87728000 + 485210
17  libdispatch.dylib              0x00007fff8dd77a86 _dispatch_call_block_and_release + 18
18  libdispatch.dylib              0x00007fff8dd792d6 _dispatch_queue_drain + 264
19  libdispatch.dylib              0x00007fff8dd79132 _dispatch_queue_invoke + 54
20  libdispatch.dylib              0x00007fff8dd7892c _dispatch_worker_thread2 + 198
21  libsystem_c.dylib              0x00007fff8825b3da _pthread_wqthread + 316
22  libsystem_c.dylib              0x00007fff8825cb85 start_wqthread + 13

FFMPEG to the rescue! Instead of trying to get DNxHD and Quicktime to play nice together, Open Source will save us, hooray! Note that some companies charge 500 euros for video conversion software, but ffmpeg will do the trick. You need to make sure you have a very recent version, as DNxHD support was only recently added. Get the ffmpeg binary from the site.

Convert the DNxHD file to something more useful using the following command line:

$ ffmpeg -i -an output.mp4
Note that this invokation strips the audio, if you want to keep it, you will have to consult the ffmpeg manual on how to do that. The ffmpeg tool recognizes the iPad2 stream with the following properties:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '':
    creation_time   : 2012-07-23 22:12:33
  Duration: 00:00:13.38, start: 0.000000, bitrate: 238657 kb/s
    Stream #0:0(eng): Video: dnxhd (AVdn / 0x6E645641), yuv422p10le, 1280x720, 220200 kb/s, 60 fps, 60 tbr, 6k tbn, 6k tbc
      creation_time   : 2012-07-23 22:12:33
      handler_name    : Apple Alias Data Handler
    Stream #0:1(eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 16 channels, s32, 18432 kb/s
      creation_time   : 2012-07-23 22:12:33
      handler_name    : Apple Alias Data Handler

Friday, July 13, 2012

Beware of automatically downscaled retina images

The iOS development environment facilitates image content loading for retina and non-retina devices with a clever naming scheme. If an iOS app is running on a retina device, and is instructed to load an image named foo.png, it will actually attempt to load the foo@2x.png file if it exists. By providing both foo.png and foo@2x.png images, both classes of devices are supported.

This convenience offered by UIKit goes one step further: if you do not provide the regular resolution version foo.png but only the retina version foo@2x.png then non-retina devices will load the high res version and automatically downscale a factor 2 so that it can be used. If you are tempted by just providing retina versions of your images, and skip the regular versions, like I was, you are selling your app short. It turns out that UIKit does a horrible job at downscaling, and the image will look considerably worse than a version that you pre-scaled yourself.

To illustrate the effect, see below how the original is downscaled by UIKit, and how it is downsampled by my authoring tool inkscape. A big difference, I would say.

The bottom line: if you care for your iPad2 and iPhone3GS Users, don't skimp on images. Provide both the foo.png and the foo@2x.png files.

The retina version of the graphic, viewed at 1:1 zoom.

The image automatically downscaled by UIKit from the retina version, viewed at 2:1 zoom.

The image, exported at non-retina resolution by inkscape, viewed at 2:1 zoom.