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 :)

Figured out the proxy to color repeating frame bug!

Matthew Rogers

Matthew Rogers

Banned
Joined
Mar 9, 2007
Messages
1,497
Reaction score
0
Points
0
Age
44
Website
www.macvilleproductions.com
Hey guys, I was going to post this in the Rowland proxy workflow thread, but I didn't want to have it buried.

After doing some testing this morning I figured out why you get sometimes get clips from the proxy workflow rendered out of Color that jump/repeat. If you have a R3D file that spans multiple R3D files and your edit goes over that break, then it seems Color freaks out and can't connect to the next the next R3D file! Say your "take" is three R3D files (001.R3D, 002.R3D, 003.R3D), if you make your edit so it doesn't cross any of the two breaks, it will render out fine--even if the take is more than one R3D file long.

I am guessing that this is the very reason RED didn't promote this workflow for the native FCP workflow. Color can't connect the R3D's through the proxies, but how RED has wrapped R3D files into a "native" mov format, it can.

So if all your takes are under 2GB, then this workflow is great (or if you can edit around the file break.) Otherwise, I would suggest editing with the offline ProRes workflow or the native file workflow.

It would be great if this could be made a sticky so people don't get confused about the proxy workflow.

Matthew
 
That's a good find.

I see jump/repeat in wrapped QT, too though.
 
That was a real nice find!

Stick this! :)

So, if we wrap the relevant proxies, we should be fine!

... Hm, thought I'd seen it in wrapped ones, too - but will have to test.

Thanks

Gunleik
 
I was wondering what caused that. Is there a way to find where each r3d ends and razor-blade the QT proxies at that point so Color opens up both files?
 
makes sense...I find that whenever I shoot a long-ish interview, I invariably have to render out a file, the proxies are very buggy with longer files. Often, if there is a break in the interview conversation, I'll hit the stop/start to break up the file size, because the shorter files are less buggy, more reliable, and easier to work with...
 
Matthew Rogers said:
Hey guys, I was going to post this in the Rowland proxy workflow thread, but I didn't want to have it buried.

After doing some testing this morning I figured out why you get sometimes get clips from the proxy workflow rendered out of Color that jump/repeat. If you have a R3D file that spans multiple R3D files and your edit goes over that break, then it seems Color freaks out and can't connect to the next the next R3D file! Say your "take" is three R3D files (001.R3D, 002.R3D, 003.R3D), if you make your edit so it doesn't cross any of the two breaks, it will render out fine--even if the take is more than one R3D file long.

I am guessing that this is the very reason RED didn't promote this workflow for the native FCP workflow. Color can't connect the R3D's through the proxies, but how RED has wrapped R3D files into a "native" mov format, it can.

So if all your takes are under 2GB, then this workflow is great (or if you can edit around the file break.) Otherwise, I would suggest editing with the offline ProRes workflow or the native file workflow.

It would be great if this could be made a sticky so people don't get confused about the proxy workflow.

Matthew
Click to expand...

Matthew,
I wished I'd seen this last night before I posted!

http://www.reduser.net/forum/showthread.php?t=23091

I actually made that same observation about the (2) R3D files, but didn't follow through with my tests to make the connection.

Thanks,
Jim
 
As I edit not with proxies, I'm conforming ProRes files getting from RR via clipfinder at the end of editing to H proxies and sending then the timeline to color... or what is faster, to export a xml at final edit, conform via clipfinder to H proxies and importing this xml to color. There seems to be the problem with the proxies ???? Any work around to get self contained Redcode QT files ???? Would be fine if redline could export them for conforming.....
 
Yes, I´ts the big shots!

Yes, I´ts the big shots!

:red_bandana: OK, its final,
I did test where I revealed in finder my trouble making shots. They all had multiple R3D files in their folders, that is each take was over 2 GB, then I removed the "big shots" from my timeline and send to color. I was smooth. I send a timeline with only "big shots" and it got stuck on the first frame so as you guys said I see for my self, color can not handle the divided files.
I have a lot of them in my footage and I can not edit around them so I will have to "wrap" them in the L/T ingestion I guess...?
Or does anyone have a better plan?
 
is there any way to conform a sequence in fcp with proxies to a self contained native R3D ? like imported with L&T native ?
 
It seams that this is not only a R3D related problem.

This also happends with Sony EX media when the clip is long. What is curious clips on EX format aren't shown as multiple files.

Maybe a color bug?


Patrick
 
I like Color, but this wouldn't be the first bug to rear its ugly head. Hopefully we can figure out an easy way around this, or Apple will take care of it in an update - soon.

Now where did I put that fly-swatter?
 
I'm going to try to test on a multiple-R3D clip tonight or tomorrow to see if trimming down the in and outs of the cut to be within each 2gb file, if that will cause Color to stop freaking out. If that works, I'll try to find out how many frames at 2:1 constitute the cutting point so I can just place a trim (hopefully) in all the problem shots at a given interval as a workaround. We'll see.

The reason I think this might work is because the shots I'm using are almost all more than 1 R3D file long (4-5 minute takes) and only a couple are having the problem. That seems to point that cutting along the right point can avoid the freakout. Now to find if/where that point exists.
 
Tim Sutherland said:
I'm going to try to test on a multiple-R3D clip tonight or tomorrow to see if trimming down the in and outs of the cut to be within each 2gb file, if that will cause Color to stop freaking out. If that works, I'll try to find out how many frames at 2:1 constitute the cutting point so I can just place a trim (hopefully) in all the problem shots at a given interval as a workaround. We'll see.

The reason I think this might work is because the shots I'm using are almost all more than 1 R3D file long (4-5 minute takes) and only a couple are having the problem. That seems to point that cutting along the right point can avoid the freakout. Now to find if/where that point exists.
Click to expand...

I can already confirm that this works. It's only when an edit goes across two files does Color freak out.

It would be great if you could figure that out, but it won't be possible since REDCODE is a VBR codec. It all depends on what your shooting, the complexity of your image, to how big each frame is. So even though frame 2,809 is the end of one file in one take, it won't be the same frame in another file:(

Hopefully Apple/RED will have a fix for proxy workflow soon. This is the only reason that I believe RED went with the "native" workflow. Otherwise, why would you suggest using a slow, clunky, workflow like that when you could use proxies?

Matthew
 
Matthew Rogers said:
I can already confirm that this works. It's only when an edit goes across two files does Color freak out.

It would be great if you could figure that out, but it won't be possible since REDCODE is a VBR codec. It all depends on what your shooting, the complexity of your image, to how big each frame is. So even though frame 2,809 is the end of one file in one take, it won't be the same frame in another file:(
Matthew
Click to expand...

Yeah, I know it's variable, but I thought that somewhere someone from RED (though I can't confirm) that it was variable in how it spread out the information per frame, but kept a constant amount of data being collected per frame. So in essence, it was variable inside of each frame, with each frame having the same amount of info.

I tried making several cuts, but it kept being buggy. I eventually cut the problematic clip into each individual frame, but it still doesn't work.

When I am having this problem, what it's doing is taking frames from other clips and playing them back all mixed together almost like a bad quad-split and some wierd coloring.

What is wierd is when instead of doing a reconform, if I start a new project with the same XLM file I reconformed with, the problem still exists, but it plays back the problematic clip completely differently, meaning that it's definately and all-color problem, and a big one at that.

Tomorrow I'll try to instead of cutting it into little pieces do the REDCODE L&T on the problematic clips. The only problem is I have that clip that is causing the problem several places in my timeline, and I don't want to re-correct all those other instances, although I could just save a preset for that clip and load it back later.

Frustrating.
 
Tim Sutherland said:
Yeah, I know it's variable, but I thought that somewhere someone from RED (though I can't confirm) that it was variable in how it spread out the information per frame, but kept a constant amount of data being collected per frame. So in essence, it was variable inside of each frame, with each frame having the same amount of info.
Click to expand...

Uhhh, that actually doesn't make sense. Well, it does, but in reality it doesn't. The RED codec can't be VBR in each frame and still have the same size frame for each frame. If it does, it's a CBR codec. Any CBR codec does exactly what you are describing above. It's got a certain amount of space to work with and it tries it's best to figure out how to get the best picture out of that amount of data space.

Sadly, I believe this whole bug is a Color problem and RED can do nothing about it.

Matthew
 
Yeah, after I thought about that more I realized it didn't make a whole lot of sense, but for some reason I remembered reading something like that somewhere on here. Must be mistaken.

What is frustrating is that cutting up the problematic clip into several pieces didn't help, all of the frames that were in the original clip just didn't work. So I'll have to try L&T to fix it. If that doesn't work, then I may have to ditch the Color workflow as this is too much of a hassle if I have to render a few clips out of RedAlert or something just to make it work. I'd wrather go through a whole different process that's the same on all clips.

It definately is a Color issue since it's bringing up different results with the same XML, so unfortunately we'll have to wait on Apple to fix it, which is never fun.
 
You must log in or register to reply here.
Back
Top