Using Pix-240 Recorder with Epic creates .movs 2 or more frames off Red Raw in Avid?

[John Moore]

Working in Avid and Resolve on an multicam Epic shoot. The down converts for offline were made in real time with Pix-240 recorders on the cameras. I assume they were fed the HDSDI feed from the Red Epic but I'm not sure. I also don't know how the timecode was sent to the Pix unit. We are finding in Avid that ama linking to the red raw files and comparing them to the ama linked .mov dnx 45 clips from the Pix recorder things are 2 or more frames different based on time code compared for the same frame of action. Production was told the Pix would be GREAT and eliminate having to do transcodes later for offline. Well given the time code doesn't match this wasn't such a good idea. Does anybody have any experience making real time down converts from the Red Epic HDSDI port. Apparently the Pix recorder will also input HDMI but I doubt that is an option with a Red Epic camera, but I'm not on the production side so I don't know for sure. Any suggestion on what went wrong in the field?

 

[stu aull]

Never tried TC-lock/dual recording with my 240 (so that is my disclaimer) -
SDI is the only way I am aware the PIX will accept TC data from the RED. If so then the fact the TC even _closely_ matches suggests that connection was used.
I know the 240 can be "re-timed" for audio delays, so presume likewise for TC?
I would contact PIX techs - very supportive and up to speed on RED interface.

'luck
Stu Aull
SX 199
PIX 240
Alaska

 

[John Moore]

Thanks for the info. I read on the site that the Pix 240 has it's own time code generator that they describe in very elaborate terms. If the time code was slaved on the Pix to incoming HDSDI which is what I assume is sent out the Red video tap there is even less reason for the time code to get out of sync. Just like with a Sony HD or SD deck when you slave to vitc or Hanc/Vanc embedded time code no matter what processing delay the signal goes through the time code stays with the picture frame and therefore stays in sync. The fact that it is off a couple or so frames, I'm not sure if the offset is the same on all cameras, points to the possibility that the embedded time code coming from the Red video tap is out of sync which would make sense if the processing delay it takes for the Red to get the senor data converted to sdi is not accounted for in the embedded time code. If what you suggest about a possible setting regarding time code offset on the Pix 240 is correct the problem could be there. Has anyone had occasion to check for embedded time code accuracy out of the Red Epic's video tape. Logic would dictate that it should match the raw files but clearly logic isn't working in our particular case. I really suspect setup error in our case. Given the Epic only has one video tap I wonder if that was somehow looped to the director's monitor and then fed back to the Pix. I doubt they used an HDMI input to the Pix. Does an HDMI output even exist on a Red Epic? Would it be an option on the additonal break out box that can be put on the back of the camera?

 

[Shane Kelly]

You can set an offset timecode on the pix to compensate for the delay out of the sdi output of the epic. You can also set an audio delay to sync audio and video ( if you are feeding audio to the pix and using the video feed from the epic) It just takes a little bit of testing for the amount of offset.
I would recommend using the pix as the timecode generator for the epic. This requires the red or w00den camera sync cable. The video feed from the epic will have a delay coming back into the epic but the pix can compensate for this. Try -2 frames to start.

Basically you need to feed the epic timecode from the pix and then find the timecode/video offset the the sdi output is introducing.

 

[Michael Romano]

PIX240 doesn't work well as an offline file generator. There is the delay (as has been mentioned) and many editorial and color software often will throw up a fit about clips that don't have the same length when conforming.

The PIX will get all metadata from the SDI feed which will always be late arriving at the record circuit.

It can however produce dalies which don't need to be conformed afterwards which can be a real benefit.

 

[Björn Benckert]

I would go the other way around the problem... 2 frames off is not to bad. How long does it take you to line up a hard committed version of your offline with a xml conform in resolve or such and just slip the clips in sync. I think you might spend less time doing that way than using the offsets, sync cables etc on the camera to get it dead on. But of course if you have the time to test and elaborate with the camera the pix and a DIT you should be able to get it to sync up, My first try would be to make the epic slave to the clock of the pix and also let the pix be the master that the sound slaves after.

 

[Shane Kelly]

PIX240 doesn't work well as an offline file generator. There is the delay (as has been mentioned) and many editorial and color software often will throw up a fit about clips that don't have the same length when conforming.

The PIX will get all metadata from the SDI feed which will always be late arriving at the record circuit.

It can however produce dalies which don't need to be conformed afterwards which can be a real benefit.

The delay is coming from the epic and can be fixed in the pix with a little bit of testing. Once you find the delay it should be fine for the rest of the show.
I think the main problem here is that the pix is probably only using the sdi input. This is fine for viewing dailies or a job that is not going to be conformed but in this case you need the sync cable with timecode and genlock. There is an ambient timecode generator in the pix ( like a lockit box ) that is very accurate and should be feeding the epic.
As for the clips being different lengths, I'm assuming that you are referring to the slight delay in the pix being triggered by the sdi feed. I don't see how this would be an issue with an edited piece but I'm interested to hear your thoughts on this.

 

[John Moore]

The problem is bigger than slipping shots 2 frames. I now have a aaf for protools which is also off on it's source time code. Slipping the shots in online is not hard but the dog chasing his tail effect if other changes come from offline are problematic. I work in the Reality TV and Variety TV world and nothing is ever locked until I see it airing. For the DIT to have suggested this workflow without actually testing it's validity is very unprofessional and as always post, especially online pay the price for a lack of competence in the field.

 

[Michael Romano]

The delay is coming from the epic and can be fixed in the pix with a little bit of testing. Once you find the delay it should be fine for the rest of the show.
I think the main problem here is that the pix is probably only using the sdi input. This is fine for viewing dailies or a job that is not going to be conformed but in this case you need the sync cable with timecode and genlock. There is an ambient timecode generator in the pix ( like a lockit box ) that is very accurate and should be feeding the epic.
As for the clips being different lengths, I'm assuming that you are referring to the slight delay in the pix being triggered by the sdi feed. I don't see how this would be an issue with an edited piece but I'm interested to hear your thoughts on this.

I don't remember the specifics, We did this ages ago when we first received our PIX240, but there was some kind of snafu moving to online when the clips had a different length, even with accurate timecode. I believe it was FCP7.x > Apple Color at the time but I honestly can't remember. The delay was indeed caused by the SDI trigger flag latency and we never could get it right. I ended up discounting the workflow because of the results but it might be worth trying again with the new AVID MC and Resolve.


John Moore has a point here as well: Often, there are serious, ghastly errors, hidden away in timecode, session management and timelines that are only found during the online or in audio post. I felt at the time that the PIX240 system for offlines was much too fragile for production environments.

 

[Robert Berger]

no time code problems with pix240

no time code problems with pix240

Working in Avid and Resolve on an multicam Epic shoot. The down converts for offline were made in real time with Pix-240 recorders on the cameras. I assume they were fed the HDSDI feed from the Red Epic but I'm not sure. I also don't know how the timecode was sent to the Pix unit. We are finding in Avid that ama linking to the red raw files and comparing them to the ama linked .mov dnx 45 clips from the Pix recorder things are 2 or more frames different based on time code compared for the same frame of action. Production was told the Pix would be GREAT and eliminate having to do transcodes later for offline. Well given the time code doesn't match this wasn't such a good idea. Does anybody have any experience making real time down converts from the Red Epic HDSDI port. Apparently the Pix recorder will also input HDMI but I doubt that is an option with a Red Epic camera, but I'm not on the production side so I don't know for sure. Any suggestion on what went wrong in the field?

Hi John, i alway use the pix240 and use the sdi out of the Epic. I'am from holland so we shoot 25fps. So the epic SDI out should stand on 25HZ and we put the pix240 to take the timecode of the sdi in, and so we do the same with audio. (for 24 fps same story put the sdi out on 24hz and so on)

Whatever you use Avid or Proress it works perfect. Very important is the sdi connection!! I had made a special SDI cable for it.
Don't let mix up AVID or proress on the same ssd from your Pix, it wil lose you desired setting every time you reboot the pix ! Always format before you change from Avid to Proress and vise versa!

best Robert