Orc is roughly following a 3-release cycle timed with GStreamer releases: features, performance, bug fixes.  This release was roughly performance+bug fixes.  After the GStreamer release, there will be a release adding new features, and the next version of GStreamer will depend on that version.  Following by a few weeks will be performance improvements, then bug fixes in time for the next GStreamer release.

Many of my recent posts have been Orc related.  Must change this…

All of the GStreamer code that previously used liboil has been converted to Orc, and will be part of the upcoming releases.  Plugins from -base that were converted are videotestsrc, videoscale, audioconvert, volume, and adder.  The change in speed is minor for now, since liboil was not used extensively.

The way that GStreamer uses Orc is intended to be very convenient for the end user:  by default when compiling from source, Orc will be used if an acceptable version is found, otherwise backup code (in C) will be used.  This backup code is automatically generated and checked in to git by a developer, so it always exists.  The configure options ‘–enable-orc’ and ‘–disable-orc’ affect this: the former causes configure to require Orc, and a configure failure is a good reminder to upgrade Orc.  The latter may be useful on architectures where Orc doesn’t generate code yet.  After a transitional phase, Orc will become required, since the more advanced uses of Orc cannot be duplicated by backup functions.

One such application that is covered is chroma subsampling and color matrixing for video, semi-incorrectly referred to as “colorspace conversion” in GStreamer.  There has been a colorspace element in Cog (cogcolorspace) for some time, but I never really bothered to do any speed comparisons between it and the default GStreamer colorspace element (ffmpegcolorspace), which is based on code copied from FFMpeg.  However, recently I did, and was somewhat surprised (although I shouldn’t have been) that cogcolorspace is the same speed as, or much faster than, ffmpegcolorspace for almost all operations.  (Please note that the FFMpeg code was forked a long time ago and heavily modified, so it does not reflect FFMpeg itself, only GStreamer’s ffmpegcolorspace.)

This is a scatter plot of the run time (in ms) for converting 1000 frames of 320×240 video between a variety of uncompressed video formats:

The axes are execution time (in ms), with cogcolorspace on the horizontal axis and ffmpegcolorspace on the vertical axis.  The green line represents same execution time, thus for points below the line, ffmpegcolorspace was faster, for those above, cogcolorspace was faster.  Most of the points clustered around the green line are statistically the same as the green line, since my timing method is quite crude.  Things to observe from this graph are that 1) many cases are very similar in speed, indicating that both ffmpegcolorspace and cogcolorspace are using similar code paths, 2) some cases, cogcolorspace is a lot faster, probably indicating that there isn’t an assembly fast path in ffmpegcolorspace for that conversion, and 3) a few cases (which, not coincidentally, are the most heavily used cases) ffmpegcolorspace is slightly faster than cogcolorspace.

The conclusions to draw from this are that 1) by writing very generic code with Orc, you can get very similar results to hand-crafted assembly code, and 2) a developer can cover a lot more cases with a small amount of work, and 3) there are a few cases where special-case Orc code would be beneficial.

This is only the low quality mode that cogcolorspace supports, which is similar or identical in quality to ffmpegcolorspace.  Higher-quality conversion is also implemented in most cases, and is only slightly slower in speed.  This is the real advantage of Orc — Orc takes care of huge number of combinations of options, and produces good SIMD code for all of them.

Orc is now to the point where it can not only reproduce about 90% of the code that is currently in liboil, but also generate 90% of the code that should be in liboil, but nobody ever wrote.  At runtime.  And the Orc language allows you to describe your own liboil-style functions.  At runtime.  Or, you can also use it like a normal compiler, converting Orc language source into N different assembly source files for every possible vector instruction set combination.

A large part of the decoding path in Schroedinger has been converted to optionally use Orc, where speed is either slightly faster or 20-30% faster than the previous liboil code.  The real benefit is that takes only a few minutes to convert code that took weeks to develop originally.  A side project of mine, Cog, has turned into a showcase for Orc, with demonstrations of video processing GStreamer elements, such as format and colorspace conversion and scaling.  I’ve found that since it is so easy and fast to create vectorized code, it now becomes possible to offer additional features to users, such as quality vs. speed tradeoffs.

Orc can generate code for MMX and SSE on x86 and x86_64, and Altivec on PowerPC, as well as NEON for ARM and c64x+DSP code.  The NEON and c64x+ backends are not currently open source.

Download 0.4.0.  Online documentation.