Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Autodesk Signs RED SDK License Agreement

M

Marc-Andre Ferguson

Member
Joined
Sep 15, 2008
Messages
24
Reaction score
0
Points
0
Age
51
Website
www.autodesk.com
http://www.studiodaily.com/main/news/prc/9909.html

OK, now that the cat's officially out of the bag, I'd like to say "hello" to all Autodesk users in RED land.
We're happy to be moving forward with this, feel free to post questions, concerns and rants here.

Jarred, can we get an Autodesk section? :-)

Cheers to my RED buddies.
 
Welcome Marc-André. (that's option-e then e for mac users)

Graeme
 
Here's a S.FL. Smoke (although I've got a Nitris at the moment because I had to retire the old Smoke :sad: ) guy who's very excited to hear the news. I've heard some great things but under penalty of death :sarcasm: can't discuss them. Let's just say Autodesk is all over the SDK and working their azzez off. Nice to have you onboard Marc-Andre.
 
Marc-Andre Ferguson said:
We're happy to be moving forward with this, feel free to post questions, concerns and rants here.
Click to expand...

I'm really looking forward for Autodesk direct import to Flint/Flame/Inferno. As owner of two Flames I found RC->DPX workflow very painful.

And one bit off-topic thought: please add timecode track option to export quicktime movies. This will make interoperability between FFI and offline editors much easier.
 
NiCKSON said:
I'm really looking forward for Autodesk direct import to Flint/Flame/Inferno. As owner of two Flames I found RC->DPX workflow very painful.

And one bit off-topic thought: please add timecode track option to export quicktime movies. This will make interoperability between FFI and offline editors much easier.
Click to expand...

Hi NiCKSON,

Not sure if you're talking about RC or FFI here. :)

But RC does export the timecode track in QT. Just fyi.

Lucas
------
ASSIMILATE, inc.
LA, CA, USA
 
luki said:
Not sure if you're talking about RC or FFI here. :)
Click to expand...
FFI doesn't have any problems with DPX AFAIK.
But rendering DPX's from RC take a loooot of time not only because of huge uncompressed files. It's two-step job, one step decode redcode to huge DPX and then import huge DPX into flame. Direct import would be nice.

luki said:
But RC does export the timecode track in QT. Just fyi.
Click to expand...

I know that. But RC is unable to output DPX and QT simultaneously. You have to translate redcode twice, in that case. And once again, this is VERY time consuming.

And TC in QT output would be nice also in other cases, generaly. I.E. when I do in flame some demo shot for such a commercial, I have to send it to editor to put it to offline for approval. Once approved, he send me back an EDL, where my demo shot is part of it. But because it came out w/o TC, it come in EDL w/ nonsense TC and thus couldn't be assembled automatically.
 
NiCKSON said:
FFI doesn't have any problems with DPX AFAIK. But rendering DPX's from RC take a loooot of time not only because of huge uncompressed files. It's two-step job, one step decode redcode to huge DPX and then import huge DPX into flame. Direct import would be nice.
Click to expand...

Two separate issues here...

1) For FFI customers, direct import would be nice. Absolutely. And I'm sure that is on its way.

2) Rendering to DPX is very much a product of what you are trying to accomplish as well as your system environment. For instance, rendering 2K DPX files from the 1/2 rez high decode from RC with the BOXX or Globalstor RED systems is approximately 21/22fps - almost realtime.

If you are rendering 4K files from the full decode, then yes - that takes a lot of storage and time.

NiCKSON said:
I know that. But RC is unable to output DPX and QT simultaneously. You have to translate redcode twice, in that case. And once again, this is VERY time consuming.
Click to expand...

Well... RC is a free program. Why not load it on two systems? :)

NiCKSON said:
And TC in QT output would be nice also in other cases, generaly. I.E. when I do in flame some demo shot for such a commercial, I have to send it to editor to put it to offline for approval. Once approved, he send me back an EDL, where my demo shot is part of it. But because it came out w/o TC, it come in EDL w/ nonsense TC and thus couldn't be assembled automatically.
Click to expand...

?

RC *does* output TC in the QT output.

Your problem may be that your editor is using an Avid for offline. None of the Avid editorial products read the TC metadata track in a Quicktime. You can test this yourself:

1) Output a Quicktime from RC.
2) Open it in Premiere or FCP. Timecode is there.
3) Now open it in Media Composer... Timecode is 00:00:00:00.

If your editor was using Premiere or FCP, then the TC you got back would not be nonsense.

Best,

Lucas
 
Welcome Marc-Andre...glad Autodesk has finally arrived. When can we expect to see support in our Smoke and Flames? Will this have to wait a year until the next extension release or will it come earlier?

an Autodesk section would be nice.
 
Hmmm. Party....

You guys probably know the drill, I am not in the liberty of saying what we're working on, and you'll just have to trust your instincts.

I can say that I'm on the IFFS team, that I was contracted, among other things, for my in-depth experience of RED workflows. Kudos to RED, Assimilate and Apple for having started this revolution, and I've been a strong supporter from day one.

One little thing we did fix in 2009 Extension 1 is the ability to import DPX sequences processed in RedCine or RedLine/Crimson, that generate different DPX filenames and tape names, and still relink to an FCP XML. It basically reads the reel IDs in the XML and matches to the first four characters of a DPX's reel ID in the file header.

At this point we don't support direct import of R3D's or QuickTimes, mainly because the Codec isn't available for 64-bit Linux, so, for now, DPX is the way to go.
 
Marc-Andre Ferguson said:
One little thing we did fix in 2009 Extension 1 is the ability to import DPX sequences processed in RedCine or RedLine/Crimson, that generate different DPX filenames and tape names, and still relink to an FCP XML. It basically reads the reel IDs in the XML and matches to the first four characters of a DPX's reel ID in the file header.
Click to expand...

nice, thanks...sounds like you spent a weekend in Mexico :)
 
Hello Marc Andre and all autodesk users,

I just bought a Smoke 2k here in France, my Red are ready to ship, I'm happy with this news.

But I was told by the French resseller taht R3D would be supported natively, like in Scratch and not decoded.

If I understand your post, it's not the case. Argh !

Please tell me !

Many thanks

Lionel
 
Marc-Andre Ferguson said:
At this point we don't support direct import of R3D's or QuickTimes, mainly because the Codec isn't available for 64-bit Linux, so, for now, DPX is the way to go.
Click to expand...

Hello Marc,
since Windows XP SP2, on which Redcine and Scratch work,
is host for Autodesk Lustre 2009, can we expect that Lustre 2009 SP1/ 2009 EXT1 will work with R3D files natively ?

Regards
 
Marc-Andre Ferguson said:
Hmmm. Party....

... the Codec isn't available for 64-bit Linux....
Click to expand...

Hi, Is it available for 32-bit Linux by now? In the RED developer SDK request form, there is still the checkbox claiming "Not yet available".

Best regards, Roman
 
Dear Marc Andre,

Maybe you know something we all don't know. Please elaborate. I have downloaded the SDK from RED and had a close look at it and my conclusion is that it won't work on 64 bit AND more importantly it is a slooowwww thing. As a Scratch owner I am very curious whether you have received a different SDK than the rest of us. Also the timing of this announcement is curious, to say the least, since there appears to be some animosity between Autodesk and Scratch. Is Autodesk playing a dirty game? Big money to kill small people? Of course I admire the products that Autodesk has made but as a world leader in sfx software it would be admirable not to try to play Bill Gates...

Maarten Treurniet
 
Hi all,

First off, I must remind you that Autodesk is a big (big) public company. I'm not in the liberty to discuss plans, features, release dates, etc. We are looking into the RED workflow, and if you'd like to share your Autodesk finishing workflow, feel free to do so.
As is written on RED's website, the Linux SDK is not available yet. Also, I am not in the liberty of discussing what the SDK lets us or not do, and that's part of the our contract with RED.
I hope you guys understand and that you remember that we're working hard for our customers.
 
We are working with REDONE for 2 movies. We have Smoke and Lustre. The best workflow we found was Final+CRIMSOM+REDCINE to DPX out put very painfull and it takes a lonnnng time. It woul be great to work directly with R3D files on autodesk softwares
 
You must log in or register to reply here.
Back
Top