Flashing on AJA SDI Output AND on Canvas

[Michael Werth]

We’ve had the same problem in varying degrees with SD 8 bit (all codecs — aja, apple, blackmagic) and nearly the identical config – DP 2.7 4G or 8G in both panther and tiger. Medea RT3Xs and CI arrays of cheetahs. Whether i install the system fresh or upgrade. Exactly the type of hits you describe. So far aja has been unable to provide a working config.

This is a HUGE headache – we’re going from one bad system to another it seems – trying to upgrade from G4s with cinewave, whose 24 fps video clips output to 29.97 tape with 3:2 started stuttering after the upgrade to Panther.

So for standard definition 24fps material going to NTSC tape the last good config we had was FCP4.0.2, Cinewave 4.0.2, on a G4 running OS 10.2.8

Not just sad – maddening.

DP1G QS 1.5G RAM Stealth FCP4.5HD, QT 6.5, CW 4.6 ATTO UL3D 8x70G Cheetah 23.98fps Targa Cine YUV OS10.2.8 **** DP2.7 G5 8G FCP4.5HD, QT6.5, OS10.3.9

[Michael Werth]

this problem does NOT go away whether material is rendered or not, whether the timeline is exported to single clip, etc. We have NOT found a workaround for this problem. Our solution is to re-insert into the dBeta if we catch the glitches by eye on layback or playback. This is not as easy as it sounds because obviously the timecode on the 29.97 tape does not match the timecode in the 23.98fps timeline. And nor can it. If you haven’t worked with 24fps material this may all be rather baffling.

8@ DP1G QS 1.5G RAM Stealth/Keyspan FCP4.5HD, QT 6.5, CW 4.7 ATTO UL3D 8x70G Cheetah 23.98fps Targa Cine YUV OS10.2.8 **** 4@ DP2.7 G5 8G FCP4.5HD, QT6.5, OS10.3.9 Kona2 1.1.4 all source material is 24fps animation created from image sequences in QTPlayer

[David Battistella]

OK>

Is this in PAL or NTSC?

Have your tried different drives? (IE media manage the project to a firewire 800 drive and try to play back from there)

Describe all of the cards and which slots they are in.

This feels like a QT or PCI bandwidth issue.

David

[David Battistella]

Also,

A smidge more detail on how your media was created/rendered, in what program etc. as this might lend a few more clues. That we are not dealing with “captured” footage might be a factor here.

David

[Michael Werth]

We usually output NTSC unlike the original poster who is working in PAL. However we do our own conversions and outputs to PAL also.

No we haven’t tried playing back from Firewire800, but it’s hard to believe a RAID0 Medea R3TX with firmware updates and Atto UL4D with current drivers can be too slow?

Kona is in slot 3, UL4D in slot 4 as recommended.

QT6.5.2, OS 10.3.9

G5 has passed hardware test. No cellphones involved AFAIK.

[David Battistella]

You are right. the drives should be planthy fast, but that is just one way of troubleshooting and making sure it is not the aray.

What program was the QT file you have imported created in and what codec are you rendering it too.

IE: If yo have an annimation codec file and you are rendering it down to DVCPRO50 then maybe you are introducing the artifacts when you are getting rid of the six lines of information in the rendered file.

FCP render settings? YUV, RGB, High Precision?

There are many variables here.

David

[Ben Holmes]

Hi All

I wasn’t going to reply to this thread until I had had the chance to try the following out on the system, but here is a customer support response from AJA:

“Hi Ben

The clue is it is happening both in the canvas and the Kona output meaning
it is not the Kona. If it is the Kona, then the canvas should remain clean.

To make sure turn off the external video and see if the canvas remains
corrupted ( toggles the external video on and off).

Suggestion:

1) Delete the FCP preferences:
a) Close FCP
b) Go to: users/username/library/preferences/FCP user data.
c) Delete the FCP preferences and cache files.
d) Go to Easy Setup Menu.
e) Make sure Show all is checked.
f) Select a Kona easy setup
g) Click on .

2) Go to Kona 2 Control Panel:
a) Close FCP ETT or Log and Capture.
a) Control: Set Default output to anything but input passthrough.
b) Control: Set Genlock to Freerun or Ref In.

3) One other possibility is bad RAM.

Keep in touch.
Thanks
Rudy ”

So – Fairly basic advice really. The system is STILL with our client, who seem to accept the workaround of exporting the timeline to quicktime before playing-out. Otherwise, they are so blown away with the speed and reliability of the system that they will accept this one bug.

I have an identical system running a digital voodoo card, with none of the above problems. So I guess my query is: If this is NOT a Kona issue (and I see where they’re coming from with this), why will changing the settings mentioned in 2) above help? I am pretty sure that the input default IS set to Input Passthrough, so I will advise the client to change the settting. I have already tried all the above 6 or 7 times anyway. As for bad ram, anything’s possible….

Keep you posted.

Ben

[Michael Werth]

we’ve done some testing since, and were surprised in small tests, that playback off the FW800 instead of the Medea RT3X showed NO glitches.

Another curiosity: When the media is on the Medea, and exporting a quicktime from the timeline to the Medea, write speeds are brutally slow. Read from Medea, write to internal or firewire, it’s fast.

Still not conclusive but promising – thanks for the advice, will post again when i think we know something.

8@ DP1G QS 1.5G RAM Stealth/Keyspan FCP4.5HD, QT 6.5, CW 4.7 ATTO UL3D 8x70G Cheetah 23.98fps Targa Cine YUV OS10.2.8 **** 4@ DP2.7 G5 8G FCP4.5HD, QT6.5, OS10.3.9 Kona2 1.1.4 all source material is 24fps animation created from image sequences in QTPlayer

[Gary Adcock]

[michael werth] “Another curiosity: When the media is on the Medea, and exporting a quicktime from the timeline to the Medea, write speeds are brutally slow. Read from Medea, write to internal or firewire, it’s fast.”

Reading a large file and then righting a version of that file back to the same logistical position is a disk caching issue. Think about it has having both hands full and you need to change which hand the objects – it is much easier when you take from one side and give to another — rather than having to set something down to pick up something else.

— Hence the reason for a multi- drive system in post.

Gary Adcock
Studio37
HD and Film Consultation
Chicago, IL USA