R3D - no supported handler

[lonnyU9HNY]

Hello all,

I am having an issue conforming a couple of specific RED .R3D clips.  I've possibly narrowed the problem down to these clips having been shot with the camera upside down and the camera operator having chosen an option to flip the image in camera.  When I open the clips in RedCineX, they are translated properly, but when I create a trimmed R3D for conform I get a "no supported handler" error from Flame (2015).   Removing the vertical and horizontal flip from within RedCineX and re-exporting does not solve the problem.  I may have to export as DPX, but wanted to check with the group to see if there may be a simple answer.  Thank you for your help!

Lonny

[yann.laforest]

Hi Lonny,

I assume that the RED files have been issued from a codec version that Flame 2015 does not support.

Can we get more information about the RED files involved here so we can confirm the hypothesis?

Thanks in advance,

Regards,

Yann

[lonnyU9HNY]

Here is some of the meta information. Let me know if you need anything in particular. Thank you for taking a look.  All other clips in the sequence were shot with the same camera with the same settings except for not being flipped. We saw this problem during production while trying to read the clips in Resolve with a RED Rocket X card attached.  The solution there ended up being to detach the Rocket and transcode those particular clips using the internal processor.

5120x2700
23.976
REDcode 6:1
No HDR
EPIC-X 5
DRAGON
DRAGON S35
REDgamma3
DRAGONcolor2

[yann.laforest]

Hi Lonny,

Thanks for getting back to me.

The media was created using the RED codec v 6.1.

The support of the RED codec v 6.1 was introduced in Flame Family 2017.

That is the reason why the media cannot be loaded in Flame 2015.

Please let me know if you have any other questions,

Regards,

Yann

[lonnyU9HNY]

Thank you, Yann. I like your theory, but it wouldn't explain why all of the other footage is read without a problem. Would the flip function be tied into the codec? How are you determining the codec used?  Is it based on the REDcode 6:1 listing?  Wouldn't that be the compression setting?  Or, are you basing it on some other information?

[yann.laforest · Accepted solution]

Hi Lonny,

Apologies for the late answer.

To answer your question, the REDcode listing is directly tied up with the codec version.  As different codec versions can used the same REDcode listing and that the codec version cannot be older than the REDcode one, we can tell that your file sample was issued using the codec 6.1 or more recent.

That being said, Flame may read RED media coming from a codec which is not officially supported by the application only if the media involved legacy decoding options.

I do not have all the details on hand but one of the option added in 6.1.6 camera firmware is the Multi Look Flip/Mirror, which might be the culprit here.

Again, the only way to validate the theory would be to load the media in Flame 2017 or 2017 Extension 1 (or in Smoke 2017) and see if the issue is reproducible in those versions or not.

Please let me know if you have any other questions,

Regards,

Yann

[lonnyU9HNY]

Thank you Yann for your help on this!  That definitely makes sense.  I will try to test the clips on an updated system.  I guess, for now, I'll export those clips as DPX sequences and go from there.