FS7: FS7RAW+ODYSSEY 7Q : 1 frame discrepency between XAVC internal and RAW external

[Francois Zaidi]

Hello

I shot a short using 7Q+ in RAW with FS7, that was also recording xavcI for proxy.
The short is editing, and I exported an XML to resolve.
When I'm linking the xavc clips to the dng ones, some clips (quite a lot), are actually not exactly synched. The RAW files is one frame earlier.
I checked into one NLE, and it is the same.
It is consistent with a 1 frame delay between the SDI trigger of the FS7 to the 7Q.

Has anybody encountered the same issue ? Is there a fix ? Or do I have to spot them and... change it by hand in resolve :crybaby:...

The odd thing is it is not concerning all clips, just most of them...

Thank you !

Edit : I found 1 more issue.
1 clip (only 1 clip) on the 7Q has the last 500 pictures black. The proxy does not. The sound, however, is stil there, so I do not think it might have been a cable signal lost !
I did not see that while shooting. Of course, I needed the shot...

 

[Viddovation]

Hello

I shot a short using 7Q+ in RAW with FS7, that was also recording xavcI for proxy.
The short is editing, and I exported an XML to resolve.
When I'm linking the xavc clips to the dng ones, some clips (quite a lot), are actually not exactly synched. The RAW files is one frame earlier.
I checked into one NLE, and it is the same.
It is consistent with a 1 frame delay between the SDI trigger of the FS7 to the 7Q.

Has anybody encountered the same issue ? Is there a fix ? Or do I have to spot them and... change it by hand in resolve :crybaby:...

The odd thing is it is not concerning all clips, just most of them...

Thank you !

Edit : I found 1 more issue.
1 clip (only 1 clip) on the 7Q has the last 500 pictures black. The proxy does not. The sound, however, is stil there, so I do not think it might have been a cable signal lost !
I did not see that while shooting. Of course, I needed the shot...

Are you saying the raw file is a frame shorter, starting a frame later than internal recording? If so, does the starting timecode on the raw file correctly reflect that it is a frame later?

It's not necessarily surprising if the raw recorder takes an extra frame to start. You have to keep in mind, there is a period of time where the FS7 has been instructed to begin recording, but has not hit a new videoframe point to send an SDI record trigger. For this period of time, the external recorder has no awareness that recording is about to begin.

If the external recorder properly marks the timecode at which it begins recording (even if that is late), modern color grading software and NLE software can place the replacement master footage correctly based on timecode. If the timecode is off, then your frames would be off in a corresponding manner.

 

[Francois Zaidi]

Héhé. Upon further investigation, I realise the frame is not shorter, but the time code is shifted by 1 frame.

Xavc first frame is 01:32:16:16 and RAW file first frame (which are the same) is 01:32:16:17. That result in a 1 frame difference when conforming to resolve. Any way around that ?

 

[Viddovation]

Héhé. Upon further investigation, I realise the frame is not shorter, but the time code is shifted by 1 frame.

Xavc first frame is 01:32:16:16 and RAW file first frame (which are the same) is 01:32:16:17. That result in a 1 frame difference when conforming to resolve. Any way around that ?

If your issue includes timecode being recorded incorrectly (off sync by a frame) then perhaps Mitch Gross will be interested. He also might have a better idea on your second issue, with black frames. That said, the black frame issue sounds like a bad cable, which might also explain your other issues.

As for timecode fixes in post... it's possible you could modify the metadata to fix the timecode, but I'm not familiar enough to feel confident on how to do that. You might want to identify all clips where it's an issue, and give them "alternate timecode" to use in the NLE, replacing with alternate timecode matching the external recorder.

 

[Francois Zaidi]

That said, the black frame issue sounds like a bad cable, which might also explain your other issues.

Well, the thing that makes me think it is not a bad cable is that the sound is OK, and being embedded in the SDI-raw. So it seems less likely.

I'm sure Mitch Gross will have some sort of explaination, or at least will acknoledge the problem.

As for the black frame, it seems that it is only one occurence in 400 takes. One too many for sure.

 

[Viddovation]

Well, the thing that makes me think it is not a bad cable is that the sound is OK, and being embedded in the SDI-raw. So it seems less likely.

I'm sure Mitch Gross will have some sort of explaination, or at least will acknoledge the problem.

As for the black frame, it seems that it is only one occurence in 400 takes. One too many for sure.

Apoligies if the confusion is mine, but you're not being precise, which is definitely desirable.

You write that you don't think it's a bad cable because the audio is okay. But you separately point out that the black frame issue only occurred on one in 400 takes. So, I understand that the audio is fine on all takes (including ones with your timecode issue), but are you specifically saying the audio was also fine on the single take in 400 that has black frame issues? And also, are we talking about all frames being black, or intermittent, or what?

 

[Francois Zaidi]

but are you specifically saying the audio was also fine on the single take in 400 that has black frame issues?

Yes. The embedded audio is fine on that specific clip.
The clip is 1889 frame long (23.976 framerate).
The clips from the beginning to 01:05:13 are fine.
Frame at 01:05:14 exibits black on the bottom (like a wipe)
Frame at 01:05:15 exibits more black at the bottom
Frame at 01:05:16 exibits even more black (the bootom is passed) - See Pix



Frame at 01:05:17 where the frame is black
All frame from here are black, up to the end.
The audio has been kept througout the clips.

I hope this cleared the potential questions.

 

[Viddovation]

Thanks.

I'd submit a official support ticket with Convergent Designs. If Mitch Gross sees this thread he may have further thoughts. At least you have the XAVC copy.

Other thoughts...
- Were you using official Convergent Designs SSDs?
- Were you close to the max storage capacity when recording this clip?
- I still wouldn't rule out a cable entirely... I've seen circumstances on other equipment where the audio might record even if the video signal fails (on the same cable)... really depends on implementation.
- Can you reproduce this problem on demand? If you can reproduce, you can troubleshoot which component or setting is making the issue occur.

 

[Francois Zaidi]

Time code offset :
My (almost) final cut encompasses 72 shots, 69 of them where recorded to the 7Q. On those 69 clips, all have a time code offset of 1 frame BUT one. That clip number 037 has the first frame at the original time code.
I want to be clear : I did not loose the first frame. It just has the next time code.

Also, the end of all clip in raw have several frame more than the xavc ones (around 9 frames more).

- Were you using official Convergent Designs SSDs? Yes (2 256GB)
- Were you close to the max storage capacity when recording this clip? No, the ssds were backed up and formatted hourly.

Black frames :

- I still wouldn't rule out a cable entirely... I have no clue, but as I understand SDI (which is not raw, I concess), if the payload is lost due to digital cliff, well here gose the audio as well.
- Can you reproduce this problem on demand? If you can reproduce, you can troubleshoot which component or setting is making the issue occur.

I don't own the 7Q. I rented it. I'm pretty sure the timecode offset is reproductible. I noticed it on conform and not before. For me, it has a 98% consistency.
As for the black frame, it happened once on 69 clips. Pretty problematic though, as you don't see the screen going black while shooting. So you discover it in post. Si I guess, if I had money to put on it, that it is ssd related, since the picture arrived all right on the monitor.

 

[Viddovation]

Could absolutely be things other than the cable. My thought that the black frames could be (at least partially) cable related works on the idea that the cable didn't stop sending (or else, you'd not have audio), but that it may have sent corrupted or incomplete video data that caused the Odyssey's codec/video stream handling to glitch, and stay broken for the remainder of the clip. I don't know enough about how the the Odyssey handles data to know if that makes sense in this case, but I've seen stranger things when it comes to data signals. All sorts of weird things can happen if you manage to overrun a buffer somewhere.

Open an official ticket with Convergent Designs, see about possibly sending them reference files. Sounds like a nasty bug.

 

[Mitch Gross]

Sorry guys, just catching up with this thread.

The timecode offset is a known issue, and it annoys us to no end. The fact is that almost EVERY camera mismatches timecode between internal recording and output signal, but the bigger problem is that it varies from camera to camera. Some even have the timecode early on the output instead of the internal. One camera that shall remain nameless had a firmware update that CHANGED the offset from two frames trailing internal to one frame preceding. What a nightmare -- now you know why we and others recommend sticking with one firmware version on all gar until a production is completed.

The offset should remain consistent throughout all recordings or at least very close to it. We are working on a timecode offset feature so that you could manually compensate for the issue. We're reticent to make it automatic because, well, things change and keeping track of various firmware builds for dozens of cameras and other devices could become a nightmare both for you and us.

As far as the shot with the dsound but no image, please reach out to cdsupport@convergent-design.com. My guess is a cable issue (about 80% of problems reported to us end up to be cable issues) but we need to investigate further.

 

[Francois Zaidi]

Thank you Mitch for the clarification.

I ran firmware 2.0. (The latest being 2.1) on the FS7.
You would think that manufacturer would be attentive to those kind of things.

I had to manually offset each clip in resolve but the number 37 (that had no offset for some reason). It just took time, so to me it is not a big deal.

Also, but I think it is known as well, the raw clips end a few frames after the internal ones. (about 9 frames). Which is not a big deal as well.

Have a nice day !

 

[Viddovation]

Thank you Mitch for the clarification.

I ran firmware 2.0. (The latest being 2.1) on the FS7.
You would think that manufacturer would be attentive to those kind of things.

I had to manually offset each clip in resolve but the number 37 (that had no offset for some reason). It just took time, so to me it is not a big deal.

Also, but I think it is known as well, the raw clips end a few frames after the internal ones. (about 9 frames). Which is not a big deal as well.

Have a nice day !

I'm in no way affiliated with Convergent Designs or any other manufacturer...

I've done enough coding and exploration of data signals to know the following: these external recorders rely on the signal in the SDI cable to provide everything: timecode, video, audio, and the record trigger. For any given camera, exactly how the SDI signal is built and what memory or hardware register it checks for timecode and the record flag may vary. Remember, a user can press the camera record button at any time during a video frame, but the SDI signal gets built at a consistent point in the frame. It's a little hard to demonstrate without pictures, but it's entirely plausible for a camera to have enough time to start recording itself prior to an external recorder having received the order. Having an electronic timecode slate on set is a wonderful tool...