New post
0

RVIO Quicktime codecs and Linux

Avatar
Nathan Rusch
None
Follow

Over the last few days I've been experimenting with MOV encoding solutions for Linux, and I'm curious whether RVIO would be able to encode DNxHD and PhotoJPEG MOV files on Linux (this is FC10, soon to be 14). I'm working on getting a trial or seat of RVIO to test on here at work, but I thought I'd ask in the meantime to see if there are already any answers.

I know RV ships with its own versions of the ffmpeg libraries, so I'm also curious what RVIO uses to do its encoding (those same libraries vs. whatever system version of ffmpeg it can find, etc.). And if it is using the shipped libraries, how up to date they are.

Thanks for any insights,

-Nathan

Date Votes

2 comments

  • 0
    Avatar
    Seth Rosenthal

    Hi Nathan,

    First, there are so many subtleties about quicktime encoding that the best way to answer these questions with 100% certainty is to test it.  We're always happy to provide eval licenses for this purpose.

    All of the below refers to the situation as of RV 3.10.13.

    About DNxHD: We face a number of challenges for supporting this codec, and so our support for it is limited. DNxHD is proprietary and licensed by Avid for a large fee, compared to the cost of RVIO. On Mac 32 and Win 32 there is an Avid Quicktime component that can be used, but the component interacts badly with RV. We do plan to make better use of the Quicktime facility for encoding, so at least on Mac 32 and Win 32 there is a path for us to add standard support for encoding.

    On ffmpeg platforms (lin64 and mac64), licensing restrictions and costs prevent us from distributing RV/RVIO binaries that support this codec.  Since RV/RVIO uses the open-source libquicktime/ffmpeg to read/write movies on these platforms,  it's possible to recompile that code to support this codec, but the resulting RV + ffmpeg code still cannot encode a DNxHD movie that Avid will recognize as valid (though playback seems to work well), and the legal/licensing issues remain.  On Apple Quicktime platforms (mac32 and win32), the Avid qt component interacts badly with RV (it looks like it wants to manage it's own threading, which can conflict with RV's threading and produce an explosion of threads).  On Win32 you can play a small number of DNxHD movies, but anything over 5 or so will cause a memory explosion (from the fact that the Avid component seems to add something like 20 threads per movie), for straight transcoding of a single DNxHD input movie, win32 RVIO seems to work fine.  On Mac32 the problem occurs even with one movie. The short answer to the encoding question is that these issues prevent us from supporting good DNxHD encoding on any platform.

    About Photo JPEG: This is our favorite quicktime codec, especially on ffmpeg platforms.  The color is reliable, and the codec provides good random access for quick uncached scrubbing.   You can encode photo jpeg movies with RVIO on any platform, but we believe the color is more reliable with ffmpeg (lin64 and mac64).

    About ffmpeg: RVIO uses the version released with the software; it won't pick up any locally installed version.  This version is a little elderly, and we plan to upgrade to the latest in the next major release (3.12, in a couple months).  This might improve DNxHD support, but the legal/licensing issues would remain.

    We'd like to improve DNxHD support on all platforms but unfortunately it's going to cost a substantial amount of time and money to make either playback or encoding really reliable on all platforms. Quicktime is a small part of RVIO, and DNxHD is one of many codecs. We would be reluctant to raise the price of RVIO for this single feature (compared to all of the other useful and unique stuff RVIO can do). One option might be to have a separate add-on product, a codec bundle, that would have an additional cost.

    Sorry to not have a more encouraging response; we'd be glad to hear what you (or anyone reading this) think of the above, so please feel free to comment further.

    Thanks,

  • 0
    Avatar
    Nathan Rusch

    This all brings to mind a quote I heard the other day: "Quicktime, not assumption, is the mother of all screw-ups."

    As far as the codecs go, I was already partially thinking that DNxHD would turn out to be hamstrung by licensing issues on Linux, so this isn't too shocking (and I can totally understand not wanting to license it from Avid if it costs more than the program you're selling). I guess I was more curious if you guys had some kind of clever way around those issues..

    On our end, it's starting to look more and more like we're either going to end up using ffmpeg command-line encoding directly on an intermediate file or output pipe from RVIO/Nuke, or have to continue supporting OSX in our render pipeline (as painful as that is). These codec decisions are out of our hands, so unfortunately we're constantly having to adapt to and adopt new configurations we otherwise wouldn't touch with a 10-foot clown pole. I was secretly hoping RVIO could be our silver bullet, but it was definitely a long shot.

    We did end up just ordering an RVIO license since it seems like it could come in handy at some point, but we haven't gotten it yet, so testing is still in the queue. I'll let you know if any other questions arise on that front.

    Thanks a lot.

Please sign in to leave a comment.