RED Team: What's up with Cross-Platform command-line RED tools?

[Bruce Allen]

RED Team:

I just wrote my first Mac command line app (a color copier for redcine). Took two weeks of my spare time. I hadn't coded for 3 years or so, so it took a while to get up to speed.

Then I wanted to make a Windows version. I copied and pasted the c++ code from my Xcode project into Eclipse (free C++ development environment on Windows, Linux and OS X). Hit compile. It worked perfectly. Took less than 1/2 an hour.

So, why is it taking you guys nearly a year to make PC versions of command-line stuff? Is it all an evil conspiracy? You know how much we PC guys are hurting, right? Do you know how much a Mac costs in South Africa? Building a Mac REDCODE renderfarm is maybe economical in the USA, but try some other countries and you hit fail pretty quickly.

EDIT: I know you guys are working hard but it's kinda crazy that Jim announces all of this cool camera stuff but there's nothing on workflow. I'm personally far more interested in a workflow roadmap than a new camera roadmap.

I think the only reason other REDUSERs aren't going nuts on this is that they don't know how easy it is to write cross-platform code.

If you're using some kind of specialized Apple libraries, then please let us know honestly and we'll understand that Windows and Linux workflow will never work as well as Mac.

It's just that you keep saying "Linux and Windows coming "soon" - which to me means "hey, we hired a Computer Science student who knows how to compile stuff for Windows and Linux. Check back for binaries in a week's time."

And then we wait months and nothing happens. So at the moment I am just a bit baffled.

Bruce Allen
www.boacinema.com

 

[OpalFilm]

Who uses Windows for serious job?

 

[Fredrik Harreschou]

OpalFilm,

that remark says more about your lack of knowledge and experience in real post production than anything else. The fact is that in the high end the market is dominated by Windows and Linux. So a kind of to answer your question:
The most serious jobs are usually done on something other than a Mac...

Tools for Windows and Linux are needed. Yesterday.

Regards,
Fredrik

 

[Cüneyt Kaya]

Who uses Windows for serious job?

please read fredriks post over and over again.

mac is fun...but it has too many disadvantages for real highend work.
thinking of the drivers for ndvidia quadros for example

 

[stephan orlandic]

who uses windows for serious job?

quantel, autodesk lustre, nucoda film master, assimilate scratch,
iridas speedgrade, nuke, fusion, ...

 

[OpalFilm]

that remark says more about your lack of knowledge and experience in real post production than anything else. The fact is that in the high end the market is dominated by Windows and Linux. So a kind of to answer your question:
The most serious jobs are usually done on something other than a Mac...

I was hoping than smiles aren't necessary for understanding jokes.

 

[Bruce Allen]

I'm not trying to start a format war. What I'm saying is: Properly-written C/C++ command line code is incredibly easy to port. Unless you are making use of special platform-specific libraries. In which case you know darn well it'll be really hard to port from the beginning.

So, the answer to porting command line apps is either "we're doing it now, it'll be out in a week." or "we used specific Mac stuff, it won't be out for a very long time". Saying "soon" and then not delivering anything for nearly a year makes no sense.

From an engineering perspective, it would be like RED saying "Hey, we're delaying releasing the RED camera for 9 months because we can't find nice cardboard boxes to ship the camera out in."

I just honestly don't see why it's taking so long. So, what's the hold up? Does the designated RED Windows / Linux porting guy / student intern want to chime in? Is there a porting guy? If not, then could RED management please let us know they're not hiring anyone to take care of this and then we can stop waiting?

Bruce Allen
www.boacinema.com

 

[Richard Goodwin]

I'm not trying to start a format war. What I'm saying is: Properly-written C/C++ command line code is incredibly easy to port. Unless you are making use of special platform-specific libraries. In which case you know darn well it'll be really hard to port from the beginning.
www.boacinema.com

As you say if the command line code is not calling "platform specific code" it might be fine. But, if they are using QuickTime and/or other Mac specific libs it is not. And, any low level optimizations that use OS specific calls might not be trivial to move over.

Remeber RED is writing a huge amount of software: The firmware that goes in the camera. I would think their software resources are pretty tied up on that. In terms of cross platoform stuff. It might not be so easy to for them to extract their command line code from all the other code. And, if you are going to release cross-platform code and have a quality product you have to QA it. You cannot leave that to an intern if you want your brand to be solid.

I'm sure RED is very aware of the need for Linux and Windows ports. Which is one of the main reasons the provided and SDK and are partnering with other software firms. But that all takes time.

As for the cardboard box comment. Write some code that calls the quickime libs and then tries to do some real-time processing. Port that to the three OS'es you mention. Then see if it is still a cardboard box.

 

[Jeff Kilgroe]

I'm going to go out on a limb and speculate that codec interfaces could be a major part of the hold up. And on Linux, we would be pretty much doomed to only output sequences of stills.

As much as I want a Windows version of REDLINE, so I can batch transcodes to a render farm, I think at this point I would rather see all of RED's coding efforts dumped into the SDK. Get a broad set of tools and open access to the RED RAW data out to developers.

But as has been said... This all takes time.

 

[Mark L. Pederson]

I'm going to go out on a limb and speculate that codec interfaces could be a major part of the hold up.

I wouldn't say that's really going out on a limb.

And on Linux, we would be pretty much doomed to only output sequences of stills.

Doomed? To work in frame sequences only?? Please send me to that hell asap!!

As much as I want a Windows version of REDLINE, so I can batch transcodes to a render farm, I think at this point I would rather see all of RED's coding efforts dumped into the SDK. Get a broad set of tools and open access to the RED RAW data out to developers.

But as has been said... This all takes time.

Agreed.

Root6 Content Agent is batch transcoded with distributed rendering on Windows via the SDK ... today.

 

[Ariana]

RED Team:

I just wrote my first Mac command line app (a color copier for redcine). Took two weeks of my spare time. I hadn't coded for 3 years or so, so it took a while to get up to speed.

One of the guys I use for post took the sdk and wrote his own command line app in a few hours. If you already know how to code, it appears to be very easy.

 

[Bruce Allen]

Remeber RED is writing a huge amount of software: The firmware that goes in the camera. I would think their software resources are pretty tied up on that.

If all their software resources are tied up writing camera firmware then they need more resources. Hire more coders. It's that simple.

And, if you are going to release cross-platform code and have a quality product you have to QA it. You cannot leave that to an intern if you want your brand to be solid.

Have you used REDCINE? RED obviously doesn't care about a high level of software QA.

I'm sure RED is very aware of the need for Linux and Windows ports. Which is one of the main reasons the provided and SDK and are partnering with other software firms. But that all takes time.

If upper management at RED were aware of the urgency they would have hired sufficient people to deal with this by now.

As for the cardboard box comment. Write some code that calls the quickime libs and then tries to do some real-time processing. Port that to the three OS'es you mention. Then see if it is still a cardboard box.

1. REDLINE is not real time.

2. Since REDLINE (the command line version) came before Quicktime could do full debayer, I highly doubt it is dependent on Quicktime code for core decode. For Quicktime output, of course you want to tie to the libraries. But just a dpx writer would be fine. Surely their dpx writing code is non-platform dependant?

So yeah, I don't see the difficulty. Still a cardboard box.

Bruce Allen
www.boacinema.com

 

[Ross Vincent]

Is there any "official" comment from RED on this?

 

[Jeff Kilgroe]

Doomed? To work in frame sequences only?? Please send me to that hell asap!!

OK, "doomed" was the wrong word. And anyone doing network rendering is going to want frame sequences anyway. I was just saying that on a Linux port of REDLINE or other tools, it would be near impossible or totally impractical to offer support for generating QTs and most types of Windows Media formats.

 

[Bruce Allen]

OK, "doomed" was the wrong word. And anyone doing network rendering is going to want frame sequences anyway. I was just saying that on a Linux port of REDLINE or other tools, it would be near impossible or totally impractical to offer support for generating QTs and most types of Windows Media formats.

I agree. That's fine. Most Linux users I know (usually Flame / Fire / Nuke artists) would love to have an option to output DPX files easily.

RED is getting a bad rep amongst these folks because they get handed crap DPX files all the time and they can't reprocess files their way on their render farms because the .R3D format is closed source and their render farms run Linux.

I'm not asking for gigantic SDK libraries or Linux Quicktime support.

I'm asking why it's taken nearly a year and RED hasn't assigned someone to just pick the low-hanging fruit and get their easiest-to-port tools out (which would require a minimum expenditure of effort on their part).

I think RED don't understand what many pro post-production people need and therefore don't understand how much this failure has hurt them.

Bruce Allen
www.boacinema.com

 

[JanneJansson]

I love a linux version of REDline. I would use still image sequences anyway to make it run on my "home-super-computer". I think tiff and openEXR is very good.

 

[Richard Goodwin]

If all their software resources are tied up writing camera firmware then they need more resources. Hire more coders. It's that simple.

There is a difference between "coders" and Software Engineers. Writing C/C++ code to process video and data via codecs is hard stuff. There is are not that many "coders" out there. It takes a lot of experience and either self-learning or often higher education. To my earlier point there are just a limited supply of people who have the skills.

Also, codec changes and enhancements would have to be ported to both the software and the firmware to stay in sync. The firmware leads right now (I'm guessing) because that is the harder segment to develop.

Have you used REDCINE? RED obviously doesn't care about a high level of software QA.

Actually, my point exactly. Just QA'ing and debugging an app like REDCINE on one platform takes a lot of work. Just like getting "coders" it takes time to build a solid QA department. QA of this type of thing requires Engineer level resources (as opposed to a basic web app for instance). Generally, when you are in startup and growth mode it is hard to do this because there are so many moving targets that having regularized testing is difficult (test plans can take as long as the software to develop).

Its not fair to say that RED does not care about QA. The cameras work pretty darn well. And, they have delivered new Builds on a fairly regular schedule. Each build has improved quality and features. So it is not that they don't care about QA. It is that they have focused their QA on their core product.

If upper management at RED were aware of the urgency they would have hired sufficient people to deal with this by now.

Upper management at RED has been focused on designing and building amazing cameras and base frameworks (codecs, and firmware). You cannot do it all at once. The SDK dev and many other Software choices have been and will be driven by what happens at the hardware level. It just works that way.

To leapfrog the rest of an industry it takes focus. You cannot build an entire company at once.

... Since REDLINE (the command line version) came before Quicktime could do full debayer, I highly doubt it is dependent on Quicktime code for core decode....

You are right. I should not have said QuickTime. But, instead should have said codec (which is what another poster said). The point being that doing development that involves codecs is hard. While the performance might not have to be real time it has to be good enough to work on medium-grade hardware (IE: not a high end server).

So yeah, I don't see the difficulty. Still a cardboard box.

This cardboard box idea bothers me because it is insulting to the Software Engineers who are working on this.

If it is such a cardboard box I offer you the following challenge: You can create a distributed processing service that Windows users can use to call the actual encoding serivce running on a Mac.

Or, how about this. Write a small MacOS emulation layer that runs on Linux so that the system calls that the Mac version of REDLINE can execute properly on a LinuxOS. If you do it right you can have one encoding process per thread. Then you should be able to encode on a 16 core linux box no problem.

After all if it is just a cardboard box that should not be so hard right?

 

[Bruce Allen]

Makex

This is how coding works:

You write ONE CODEC / SET OF DECODE FUNCTIONS TOTAL. Not one set PER PLATFORM.

You call that function from your platform-specific code.

The platform specific stuff is just a wrapper. EG a cardboard box. Which can be done by a lower-level programmer.

I believe this statement invalidates most of your lengthy post.

Although I agree RED should definitely hire more coders too (and pay them the going rate, which should be high), that is not the topic of this thread.

Bruce Allen
www.boacinema.com

 

[Kyle Mallory]

Bruce,

I'm glad to see someone else harping on this other than me. Thanks!

I need to confirm my sources first, but I recall reading a post that RedLine for Linux will only support TIFF, DPX, and one other single-frame format, which I can't recall off head. I'm trying to find that post...

As for getting MOV/AVI formats from Linux, once the SDK is available for linux, you should be able to use FFmpeg or GStreamer to process a sequence of stills into a more mainstream format.

Remember that AVI and QuickTime are not codecs, they are "containers" which wrap a variety of codec streams, some proprietary (like ProRes) but many industry standard (such as MPEG4, YUV, DV, MPEG2, etc), which have been available on Linux for years, successfully.

Bruce is right. Porting the command-line tools *should* be trivial. However, I believe there may be bigger issues with things like libraries and possibly even some hand-cooked assembly that maybe causing some delays.

Sadly, I commented on this nearly two years ago, that RED should take care in developing their tools to be platform independent, from the beginning. Apparently that didn't happen and now we (the 1% of the userbase) are suffering.

 

[reality]

Quicktime on Linux is a huge pile of half baked crap. Many functions are missing, half working or not even there. Simple stuff like implementing timecode properly is mess.

Porting tools is not always trivial. Sometimes it's more important to get a tool out on one platform faster which means taking a non compatible route. Sure you can make everything cross platform but that can take huge amount of time if the libraries don't exist on all platforms. Been there, done that.

It's funny how everything is trival when it's not your responsibility.