Portable Field Transcoding with Small-Form-Factor Computers

What if you need to transcode files when you’re in the field, in between production shoots or as a way to push digital dailies out to local clients? In a studio, you’d upload the master file to an online video platform (OVP) or an online encoding engine. But if you’re in the field, you may be at the mercy of what you have on hand.

Based on that scenario, Transitions has been running a number of tests to find a good balance between size and speed. We'll share those results here.

Test File and Outputs

We used an open-source video file of feature length, which had an 81-minute total running time and had been initially rendered at 1080p at 7.24Mbps, for a 4.43 GB total file size. The original file was rendered at 23.976 frames per second (fps) using 48 kHz AAC stereo audio.

From that, we planned to transcode three different data rates to MP4 files which were optimized for playback on iOS devices, including iPad, iPhone, and iPod touch, as well as Apple TV set-top boxes: 5Mpbs, 3Mbps, and 1.5Mbps. All three were output at 1080p, with the original frame rate and AAC+ version 1 audio, which was down sampled as part of the transcoding process from 48 kHz to 44.1 kHz stereo at 128 Kbps. For those interested in replicating our tests, the original 4.43 GB 1080p file from which we transcoded all our test outputs is available from the official site here.

Software

To encode the files, we used Adobe Media Encoder CC 2014 (AME), which provides a decent parallel processing experience utilizing as many cores as are available to the software, and offers choices between software-only and hardware-assisted transcoding modes. This was key to our tests, as we knew that Adobe’s 2014 version of AME has Open CL capabilities, which certifies some non-NVIDIA graphics processors—including, it turns out, one of the integrated Intel GPUs we tested—via Adobe’s Mercury Engine technology.

As we found out in our previous testing, AME does not provide a way to multiplex the transcoded video files themselves into MPEG-2 Transport Streams (.ts or M2TS) for use in Apple’s HTTP Live Streaming (HLS) while Apple Compressor does. Still, with AME being cross-platform, we thought it prove the best way to test hardware built specifically by Apple against hardware typically used in non-Macintosh environments.

That being said, if one were to deliver these MP4 files to a just-in-time or on-the-fly HLS or Smooth Streaming segmenting or packaging server, the MP4 files that Adobe Media Encoder delivers are more than adequate in terms of quality and format compliance to allow the media server to parse out these segments.
To be certain of this fact, we ran several online tests, in which we uploaded the MP4 files, immediately after transcoding, to a media server. In addition, we ran each transcoded MP4 file through Apple’s command line interface tool—known as MediaFileSegmenter, which Jan Ozer has discussed at length in his StreamingMedia.com articles—and then uploaded a main.ts pre-segmented file, along with an m3u8 manifest file, to an HTTP-centric media server. Both performed equally well on either the JIT or traditional server, but the performance results are not part of this article, as the testing was designed to provide the company an internal baseline for testing its media server.

In addition, we created a brand new user account on each machine, so that no stray applications would eat in to CPU, GPU, or memory resources. We named this user Small Boxes, in honor of our test machines.